How to Protect Your Cloud Data with AWS Secrets Manager

In April 2018, AWS announced yet another game-changing service, AWS Secrets Manager. As its name suggests, this service manages all of the secrets (passwords, keys, tokens, database credentials, etc.) that you need for your cloud resources. This is an exciting development, as keeping track of secrets after resource provisioning is a major challenge when working in the cloud. Secrets can be vulnerable and difficult to manage, especially in large numbers. In the past, organizations used third-party applications like HashiCorp Vault to manage their secrets with multiple encryption algorithms. The Secrets Manager has removed this burden, making the process much simpler and more user-friendly.

AWS Secrets Manager Features and Benefits

AWS Secrets Manager offers many features and benefits, including:

Rotating Secrets

As you likely know, rotating secrets is a security compliance for most organizations, although not all of them actually do this. While some organizations do write custom automation scripts to rotate secrets at frequent time intervals, this requires specifying the latest secrets in the application configurations and may necessitate application deployments. AWS Secrets Manager assures that your application will get the latest rotated secrets since an API call will always return the latest versions.

Integration with AWS Services

AWS Secrets Manager integrates seamlessly with other AWS services. This means that from now on, you don’t have to store database credentials and manage them using third-party applications. Rather, these credentials are just an API call away from the application. In addition, secrets are not limited to the databases running in AWS—you can also store and manage API keys, OAuth tokens, and more.

Easy Management

Using AWS Secrets Manager is simple. Just make an API call and it will retrieve the credentials for you. It also automatically manages the credentials of resources running in AWS, rotates secrets after a predefined interval of time, and allows you to control access to your secrets. You can also use IAM policies to provide the required access to relevant users.

Fine-Grained Policies to Manage Access

With AWS Secrets Manager, you can manage access to secrets using fine-grained policies. For example, an IAM policy will allow developers to retrieve credentials for the development environment. The same policy may have a different rule that allows the same set of users to retrieve credentials for other environments, but only if accessed from a certain set of IPs. Using AWS Secrets Manager, you can also manage SSH keys and provide fine-grained access to relevant users.

Security of Secrets

We’re talking here about the security of your secrets—sounds funny, right? Basically, because some people don’t trust AWS, they want to secure their secrets—and ironically, AWS Secrets Manager supports this. You can use AWS KMS to encrypt secrets with your custom key and store. When accessed, the secrets will be decrypted using the same key that was used to encrypt.

Pay-As-You-Go Pricing

Like other AWS resources, AWS Secrets Manager offers a pay-as-you-go pricing model that enables you to pay for the number of secrets stored and the number of API calls made. This allows you to manage your secrets with no ongoing infrastructure maintenance costs or upfront investments.

Use Cases

You can apply AWS Secrets Manager to many different use cases, such as:  

Managing Orchestration Tool Secrets

Orchestration tools like Kubernetes and OpenShift manage the complete lifecycle of dockerized applications. When using these tools, creating secrets is easy, but maintaining them is very difficult since the secrets are maintained on the cluster or through third-party applications like HashiCorp Vault. Orchestration tools allow users to maintain cluster-level permissions, and the cluster console provides access to the secrets defined in the console. Managing these secrets through AWS Secrets Manager can help you define different levels of permissions to the secrets, and people with console access to the cluster will not be able to access them.

Managing Database Secrets in Applications

With three-tier architectures, the application server needs access to the database. To manage database access, different users are created with different levels of permissions. Restricting access to this information is a must in order to provide security to the architecture. Using AWS Secrets Manager, you can easily define secrets and avoid managing them with third-party applications or your own tools.

Auditing Secrets

To keep an eye on your secrets, you have to audit them. You can do this by integrating AWS Secrets Manager with AWS CloudTrail, which allows you to keep a record of when the secrets were last accessed and modified, as well as to perform various auditing activities.

Security Compliance Standards

All organizations follow at least some security compliances, which not only protects applications from threats but also defines a set of protocols to be followed in the future. When working in a large organization, sharing and storing secrets is a must. Still, whether an API token, an OAuth token, or an application key for the development, staging, or production environment, secrets should not be shared publicly. Certain organizations even restrict engineers from sharing secrets via email or other communication channels. This involves using third-party tools such as 1ty.me, which creates a self-destroying URL that can be easily shared. Of course, sharing your own secrets with a third-party service is also not recommended. AWS Secrets Manager’s many features (discussed in more detail above) offer solutions. For example, you can share secrets by uploading them on the service and managing their access using fine-grained policies, and can automatically manage your credentials rotation policy. Using AWS CloudTrail, you can also audit your secrets and easily track any modifications. Since CloudTrail is integrated with AWS, other services can retrieve the credentials by simply sending an API call. This eliminates the hassle of storing secrets.

Managing Secrets in Automated Pipelines

DevOps are constantly emphasizing the importance of continuous pipelines to move code from dev to production. This way, the code passes through stages like unit tests, functional tests, and integration tests. In the package creation stage, the code is pulled from the repository and then packaged so it can be stored in a private artifactory. The new code then deploys to respective environments through an internal network. Of course, all of these stages involve secrets (artifactory, repository, cluster, etc.) that must be managed and stored. CI/CD servers, such as Jenkins, GitLab, and others, manage these secrets on their disks—as do the users with master permissions. This is a loophole in the system since it is very difficult to identify the culprit if someone modifies the secrets. Using AWS Secrets Manager, you can store your secrets on AWS; and with a simple API call, can retrieve the credentials from AWS. This not only prevents your secrets from being modified but also manages their rotation policies.

Conclusion

If you’re looking for automation and innovation, AWS Secrets Manager is an exciting new service. Gone are the days when you had to manage your secrets, define their rotation policies, and audit their modifications. AWS Secrets Manager does all of this for you, giving you more time to focus on the application itself. Now, you no longer need to deploy an application in order to retrieve the latest secrets, as every curl request (API call) fetches the secrets and injects them into the application’s environment variables. Basically, AWS Secrets Manager acts like a security engineer, providing multiple ways to maintain and manage secrets automatically. So what are you waiting for? It’s time to start redistributing your security tasks to AWS Secrets Manager, and explore what this enables you to do.

Read Also

• How to Copy EBS Snapshots to Amazon S3 and Save on Storage Costs
• 7 Steps to Save Big on Your AWS Bill
• 10 Tips for a Solid AWS Disaster Recovery Plan

 ]]>