Secrets Management Best Practices: Secure Cloud-native Development Series

Build secure cloud-native applications by avoiding the top five security pitfalls we lay out in our Secure Cloud-native Development Series. This blog is the fifth and final part of the series, and it will teach you to handle credentials and secrets management best practices for securing cloud-native applications.

Every organization has their way of managing credentials. In the past, with legacy application architectures, this was a bit more manual and arduous. With cloud-native applications, we have options open to us that are seamless for handling credentials and secrets management. The level of sensitivity of the data will designate the means we use to protect credentials.  

Obviously, never check-in credentials to code repositories. But again, utilizing the cloud providers secret manager/vault can help us strengthen our security posture and minimize risk for leaked credentials within the architecture and application.  

Best Practices for Secrets Management & Secure Cloud Development 

AWS has Secrets Manager, GCP has Secret Manager, and Azure has Key Vault.  In short, we store our secrets with these services and can reference them in our deployments and applications. For a simple example, our deployment configurations may include virtual machines or services that require a password or a secret. I have seen deployments where a hardcoded password is used and another service may pick up after and change those credentials as they may be managed in another way.   

Remember if the plan is to go cloud-native, why complicate things?! Keep secrets centrally managed and reference them in a secure way. Here is an example of an Azure Deployment template utilizing a Windows password stored in Key Vault.   

First, we create the secret or password that will be used for our service.

Second, here we see the reference in the deployment template pointing to our WindowsServerPassword secret stored in Key Vault.

Lastly when deployed, we can see the value pulled from Key Vault and our VM is now running with that password for further configuration.

Keys, passwords, and other sensitive strings or secrets may still end up being stored in source code repositories (shame on you!). Whether it is intended or a possible accidental commit, it happens. So how do we deal with it?    

Tools to Help with Credentials and Secrets Management 

Gitleaks is a useful tool. It can be run periodically and output into multiple formats when ran manually. Additionally, it could be added into your CI/CD as a pre-commit hook in the repository itself, or with something like GitHub Actions. Using the tool against the leaky-repo which is meant for testing this sort of thing, we can see the output and detections. 

Why it’s important: Of course, your code is being statically scanned through a reliable vendor, 😉 which also scans for hardcoded credentials. By doing this, you will get better coverage through a commercial product. However, we may a use a certain code base that we are not scanning currently. This tool can help, but also can be another set of eyes on our current toolset.  But whatever our solution is, we should have a detection tool in place that will help find secrets like this. 

Secrets Management Takeaways 

Using a vault, whether through the cloud provider or a cloud agnostic tool like Hashivault, all secrets can be safely stored and retrieved safely and even rotated automatically with no changes to the application code. A good reference around continuous integration and continuous deployment is the OWASP Cheet Sheet. We should be rotating application credentials regularly (and automatically). We should also have a process to detect that we do not have any hardcoded secrets. As well as simplify our process where possible to lessen the risk of credentials and tokens being leaked. 

Secure Cloud-native Development Series Conclusion 

Throughout this series we have highlighted the benefits of utilizing cloud-native services where possible when deploying our applications and architectures to the cloud.  The main point is not trying to reinvent the wheel. Use integrated cloud services where possible. Obviously, the costs go up the more we utilize, however, the amount of setup, configuration, and maintenance all decrease with managed services.   

We discussed the importance of being cognizant of our cloud deployments (meaning we want to ensure we are deploying the intended configuration). We discussed gotchas with container images as well as access control with storage.  We discussed services that can help with managing application secrets as well as logging for deployments. Lastly, enable encryption on all your stuff! 

Clearly we can see the benefits of migrating our services to new technologies running on cloud workloads – but be beware of the gotchas we talked about – happy deploying!