How to deploy Kubernetes Secrets with AWS Secrets Manager

Tl;DR: Unlock the power of external secrets in Kubernetes for optimal security. Learn how to integrate secrets from AWS Secret Manager to Kubernetes effectively.

10 months ago   •   5 min read

By Kamal Acharya
In this article

In Kubernetes, external secrets refer to managing sensitive information, such as API keys, database passwords, or other credentials, outside of the Kubernetes cluster and then securely injecting them into the cluster when needed.

This approach is crucial for several reasons:

  • Security: Storing sensitive information directly in Kubernetes manifests or configuration files is a security risk. External secret helps to reduce the risk by keeping the data separate from the application code and configuration which reduces the chance of accidental exposure or misuse of credentials.
  • Separation of Concerns: Externalizing secrets allows us to separate application code and configuration which is a major concern. It allows developers to focus on writing code without worrying about handling sensitive data. The operations team can manage secrets separately by applying the best practices without impacting application logic.
  • Centralized Management: External secrets facilitate centralized management of sensitive information. This means secrets can be stored, rotated, and audited in a centralized system outside the Kubernetes cluster. Centralized management simplifies the task of maintaining and updating credentials without the need to modify application code or configurations.
  • Dynamic Secrets: Some external secret management systems support dynamic secrets, which are credentials that are generated on-demand and have a limited lifespan. This enhances security by minimizing the exposure window for sensitive information. Kubernetes workloads can request dynamic secrets as needed, reducing the risk of unauthorized access.
  • Integration with Secret Management Tools: External secrets can be integrated with different secret management tools like HashiCorp Vault, AWS Secrets Manager, etc. These tools provide advanced security and features such as encryption, access controls, and audit trails.
  • Compliance: Many organizations need to adhere to specific compliance standards that mandate secure handling of sensitive information. Externalizing secrets and leveraging external secret management tools can help meet these compliance requirements.

In this blog, we will dive into AWS Secrets Manager and deploy secrets in Kubernetes, streamlining the secret management using Devtron.

Secrets Management Tools

Kubernetes by default uses base64 encoding for the secrets that are being created. Base64 encoding is not a strong encryption algorithm that should be used for sensitive data like passwords, API-server endpoints, tokens, etc. To solve this challenge, there are a lot of other third-party secret management tools available, supporting a variety of encryption algorithms for the secrets. Here are some popular secret management services/ tools available today;

  • HashiCorp Vault: A tool for managing secrets and protecting sensitive data.
  • AWS Secrets Manager: A service for managing sensitive information used by AWS services and applications.
  • Azure Key Vault: A cloud service for securely storing and managing secrets.
  • Google Secret Manager: Managed service provided by Google for storing secrets and confidential data.

Deploy secrets from AWS Secret Manager in Kubernetes using Devtron

💡
The only prerequisite to follow along is to create secrets in the AWS Secret Manager, and install Devtron

To add secrets in the AWS secret manager, do the following steps:

  1. Go to the AWS secret manager console
  2. Click Store a new secret
  3. Add and save your secret
AWS-Secrets-Manager-UI
AWS Secrets Manager UI

Deploy secrets in Kubernetes

Step 1: Deploy External Secret Operator (ESO)

external-secrets-operator-architecture
External Secrets Operator Architecture

External Secrets Operator is a Kubernetes operator that integrates external secret management systems like AWS Secrets Manager, HashiCorp Vault, Google Secrets Manager, Azure Key Vault, and many more. The operator reads information from external APIs and automatically injects the values into a Kubernetes Secret.

Helm chart link: https://charts.external-secrets.io

Step 2: Deploy the aws auth creds in secret name aws-secret-auth

Create a Kubernetes secret in the namespace in which the application is to be deployed using base64 encoded AWS access-key and secret-access-key. You can use Devtron's generic-helm-chart for it.

💡
Note: If you want to authenticate AWS Secrets manager using Service Account or IAM roles, that can also be achieved. This is the basic implementation to authenticate with AWS
aws-secret-auth
AWS Secret Auth

Step 3: Create a secret for your application

Go to the App Configuration >> Secrets and click on Add Secret

add-secret
Add Secret

Select AWS Secrets Manager under External Secret Operator (ESO) from the drop-down. You can also see all other options available, and if there are requirements of any other third-party secret that is not available as of now, that can also be supported as long as it is supported by ESO.

  • AWS SecretManager
  • Google Secret Manager
  • Hashi Corp Vault
aws-secrets-manager
AWS Secrets Manager with Devtron

Step 4: Configure the secret

To configure the external secret that will be fetched from the AWS Secret Manager for your application, you will need to provide specific details using the following key-value pairs:

Key

Description

aws.region

Specify the location where secret is present

aws.auth

Specify the secret name where creds are present

secretKey

Name of the secret created

key

AWS Secret Manager secret name

property

AWS secrest Manager secret key

secretStore-auth with access-keys
secretStore Auth with accessKey and secretAccessKey

If you don't want to authenticate using access-key and secret-access-key, attach the SecretManagerReadWrite policy to your node and then the system should automatically fetch the secrets from the secret manager and deploy it into your Kubernetes cluster.

attach-permission-to-the-role
Attach Permission to the Role

Once the policies are attached, you can change the SecretStore configs as specified below.

secretStore-configs-with-noderole
secretStore Configs with NodeRole

Once the authentication and secret keys are provided, you can save the secret and deploy the application. Devtron automatically does the heavy lifting of fetching the secrets from AWS Secrets Manager and mounts them to your applications. No manual intervention is required in this case.

💡
Interested in mastering the use of HashiCorp Vault within Kubernetes?
Dive into the insightful blog to grasp how to deploy the Hashicorp Vault and fetched secrets into the Kubernetes.

Conclusion

Leveraging external secrets in Kubernetes goes beyond just securing applications—it’s about building a resilient, future-ready infrastructure that empowers innovation and mitigates evolving threats. Tools like AWS Secrets Manager and HashiCorp Vault bring structure, security, and reliability to the often chaotic realm of secret management. Adopting these practices today not only protects your assets but also lays the foundation for scalable growth and operational excellence. Devtron tends to streamline the entire secret management bringing everything under one roof, to make the entire Kubernetes-native software delivery a breeze for users.

If you have any questions or need further guidance, don’t hesitate to connect with us! Join the conversation in our vibrant Discord Community—we’re just a click away!

Related articles

Spread the word

Keep reading