Security & DevOps
Hardcoded passwords, committed API keys, and plain-text connection strings remain one of the leading causes of enterprise data breaches. Here’s the correct pattern – and how to implement it in ASP.NET Core today.
If your ASP.NET Core application has a database password in
appsettings.json, a connection string in your CI/CD pipeline, or an API key committed to source control – you have a security vulnerability. Not a theoretical one. A real, actively exploited one. This post explains the right pattern and how to implement it with AWS Secrets Manager.
The most common response to this topic is: “We’ll deal with it later.” But the breach statistics tell a different story. Exposed credentials in source code, build logs, and environment files represent one of the top attack vectors in cloud environments year after year. The good news is that the fix is not complex – it’s a configuration change backed by a clear architectural pattern.
The Problem: Where Secrets Live Today (And Shouldn’t)
In many .NET applications, secrets are scattered across several insecure locations. Understanding where the exposure points are is the first step to eliminating them.
The Right Pattern: Runtime Secret Retrieval
The principle is straightforward: your application should never contain secrets at rest. Instead, it should retrieve them at startup from a trusted, access-controlled vault – and hold them in memory only for the duration of the process.
In a modern cloud environment, this is achieved through the combination of two mechanisms. First, the hosting environment (an EC2 instance, an ECS task, a Lambda function, or a Kubernetes pod) is granted an IAM identity — an instance profile or a task role. Second, AWS Secrets Manager is configured to grant that IAM identity read access to specific secrets. The application never needs to know a static credential; it authenticates by virtue of where it is running.
“The hosting environment proves who the application is. AWS Secrets Manager decides what secrets it’s allowed to see. No static credentials needed.”
How It Works in ASP.NET Core
Integrating AWS Secrets Manager into an ASP.NET Core application is a well-supported pattern. The AWS SDK provides a Secrets Manager client, and secrets can be loaded into the .NET configuration system at startup so they are accessible anywhere IConfiguration is used.fa
Step 1: Add the AWS SDK Package
Step 2: Build a Configuration Provider
Step 3: Register at Startup
How Hangfire Fits In
A subtle but important point: Hangfire’s job store also needs database access – and it runs as a separate service from the main web API. This means it cannot simply inherit credentials from the web API process. It must retrieve its own secrets.
The solution is identical: assign an IAM role to the Hangfire hosting environment (which may be the same process, a Windows Service, or a separate container), grant it read access to the relevant secret in Secrets Manager, and load the configuration using the same pattern shown above. Because Hangfire integrates with the .NET configuration system, there is no Hangfire-specific secret handling required – it reads the connection string from IConfiguration just like any other .NET component.
Secret Rotation: The Underrated Benefit
Beyond the initial security improvement, AWS Secrets Manager enables a capability that most self-managed secret stores cannot easily provide: automatic credential rotation.
Common Objections and the Answers
“We’re not on AWS, we’re on Azure”
Azure Key Vault provides an equivalent service with near-identical capabilities – managed identity authentication, secret versioning, rotation support, and full audit logging. The pattern is the same; only the SDK and IAM mechanism differ. The ASP.NET Core configuration provider for Azure Key Vault is available via the Azure.Extensions.AspNetCore.Configuration.Secrets NuGet package.
“This adds latency to our startup time”
Secret retrieval from AWS Secrets Manager typically completes in under 50 milliseconds within the same region. For a service that starts once every few hours at most, this is negligible. Secrets Manager also supports caching via the AWSSDK.SecretsManager.Caching package, which eliminates repeated network calls entirely after the first retrieval.
“Our on-premises database doesn’t support IAM roles”
IAM roles govern access to Secrets Manager – not to the database itself. Your on-premises MySQL instance continues to use a username and password. What changes is where that password lives: in Secrets Manager instead of a config file. The database doesn’t need to know anything about AWS.
The Compliance Upside
Beyond operational security, this pattern directly supports several compliance requirements that enterprise organisations commonly face. SOC 2 Type II requires evidence of access controls and audit trails for sensitive credentials. ISO 27001 requires a formal secret and key management process. PCI-DSS requires that credentials with access to cardholder data be protected and regularly rotated.
With Secrets Manager, the audit trail is automatic, the access controls are IAM policies (which are already being managed as part of your AWS governance), and rotation can be configured once and run forever without manual intervention. Compliance becomes a by-product of good architecture rather than a separate programme of work.
Conclusion: Security Should Be the Default
Secrets management is not a nice-to-have for mature teams – it is the baseline for any application handling real business data. The pattern described here – runtime retrieval from AWS Secrets Manager using IAM-based authentication, with no static credentials in any file or pipeline – takes an afternoon to implement and provides lasting security benefits.
For teams building on ASP.NET Core, this pattern integrates seamlessly into the existing configuration system. For teams running Hangfire as a background processor, the same approach applies with minimal additional work. And for compliance-minded organisations, the audit trail, access controls, and rotation capability of Secrets Manager reduce the manual effort required to meet most certification standards.
If you’re ready to move your credentials out of config files and into a proper vault – or if you want to review your current secrets posture – our team can help you get there quickly and safely.
Let’s Secure Your .NET Application
From secrets management to full architecture reviews, our team helps enterprises build and maintain applications that are secure by design – not as an afterthought.
About the author:
Nilima Mandhane – Sr. Manager – Projects
Nilima Mandhane, a B.E. in Computers, is a seasoned technologist skilled in PowerBuilder, .NET, and Microsoft technologies. With experience across industries like garments, logistics, banking, and facilities management, she has delivered successful projects in India, the UK, Germany, the USA, Dubai, and the Netherlands. Known for solving complex challenges and driving business growth, Nilima’s attention to detail and passion for innovation make her a valuable asset to any project