Enhancing AWS Security: The Case for Customer-Managed Keys in Secrets Manager

Overview

Managing credentials, API keys, and other sensitive data is a cornerstone of cloud security. While AWS Secrets Manager provides a robust service for storing these assets, the real measure of security lies in how they are encrypted. By default, AWS uses an AWS-managed key, which offers a basic level of protection but limits your control over the encryption lifecycle.

This default configuration creates a significant governance gap. True data sovereignty and security require granular control over who can access sensitive data and under what conditions. For organizations with strict compliance requirements or a mature security posture, relying on default keys is insufficient.

The best practice is to encrypt secrets using Customer-Managed Keys (CMKs) provisioned through the AWS Key Management Service (KMS). This approach provides an essential layer of control, enabling you to manage key policies, rotation schedules, and audit trails independently, aligning your security operations with the principle of least privilege.

Why It Matters for FinOps

Adopting Customer-Managed Keys is not just a security decision; it has direct implications for FinOps and business risk management. Relying on default encryption keys introduces financial and operational risks that can be costly to mitigate later. The initial convenience of default keys often leads to significant technical debt, requiring complex and risky migration projects as the organization scales.

From a risk perspective, using a single default key increases the "blast radius" of a security breach. If a compromised IAM role has permission to read secrets, it can access every secret encrypted with that default key. Segmenting secrets with different CMKs contains the potential damage, limiting a breach to a specific operational domain.

Furthermore, failure to demonstrate independent control over cryptographic keys can lead to audit failures for compliance frameworks like PCI DSS, HIPAA, or SOC 2. These failures can result in hefty fines, loss of certifications, and significant reputational damage, all of which carry a direct financial cost.

What Counts as “Idle” in This Article

In this context, an "idle" configuration refers to a secret that is not actively managed under customer-defined security policies. Specifically, any secret within AWS Secrets Manager that relies on the default AWS-managed encryption key (aws/secretsmanager) is considered to have an idle security posture.

This configuration is "idle" because key management responsibilities—such as access control, rotation policies, and revocation capabilities—are delegated to AWS and are not under your direct control. Signals of this idle state include:

• A secret’s configuration pointing to the default AWS-managed key.
• The absence of a specific KMS Key Policy governing access to the secret’s encryption key.
• An inability to control the key’s rotation schedule or disable it during an incident.

Common Scenarios

Scenario 1

A central security team is responsible for managing cryptographic keys for the entire organization. Application teams in separate AWS accounts need to store and access their own secrets. By using a CMK created in the central security account and sharing it with the application accounts, the security team retains ultimate control, including the ability to revoke access organization-wide during a security incident.

Scenario 2

An application needs to grant a third-party vendor access to a specific database credential. The secret is encrypted with a dedicated CMK. The key’s policy is configured to grant decryption permissions only to the vendor’s specific IAM role. This ensures the vendor cannot access any other secrets in the account, even if they attempt to, enforcing strict data segregation.

Scenario 3

A company has a compliance mandate requiring all encryption keys for sensitive data to be rotated every 90 days. The default AWS-managed key rotates automatically every three years, a schedule that cannot be changed. By using a CMK, the team can configure an automated annual rotation or perform manual rotations on demand to meet the 90-day requirement and provide evidence to auditors.

Risks and Trade-offs

The primary risk of not using CMKs is a weaker security posture. It centralizes trust in IAM policies alone, removing the critical second layer of defense provided by a key policy. In the event of a breach, the inability to quickly disable a key to render secrets unusable—a "kill switch"—can dramatically increase the time to containment and the extent of the damage.

The main trade-off is operational overhead. Managing CMKs requires more setup than using the default key. Teams must create the keys, define robust key policies, and ensure application roles have the necessary kms:Decrypt permissions. Migrating existing secrets from the default key to a CMK must be planned carefully to avoid disrupting production workloads, as applications will lose access if their IAM permissions are not updated correctly. However, this initial investment pays significant dividends in long-term security and governance.

Recommended Guardrails

To enforce the use of Customer-Managed Keys and avoid configuration drift, organizations should implement a set of clear governance guardrails.

Start by establishing an organizational policy that mandates CMK encryption for all new secrets. Enforce this policy through Infrastructure as Code (IaC) linting tools or AWS Service Control Policies (SCPs) that deny the creation of secrets without a specified KmsKeyId.

Implement a robust tagging strategy for all CMKs to identify key owners, associated applications, and data sensitivity levels. This simplifies auditing and chargeback/showback processes. Configure automated alerts using services like AWS Config to detect any secrets created with the default key, enabling rapid remediation. Finally, establish a clear process for key lifecycle management, including rotation schedules and procedures for decommissioning keys.

Provider Notes

AWS

In AWS, this practice centers on the integration between AWS Secrets Manager and AWS Key Management Service (KMS). When you store a secret, Secrets Manager uses KMS to perform envelope encryption. You have two choices for the key: the default AWS Managed Key, which is shared and managed by AWS, or a Customer Managed Key (CMK), which you create and control. A CMK gives you full control over the key policy, which acts as a second authorization layer on top of IAM, and allows you to manage the key’s lifecycle, including rotation and deletion.

Binadox Operational Playbook

Binadox Insight: Relying on IAM policies alone for secret protection is insufficient. A Customer-Managed Key provides a crucial "double lock" mechanism, ensuring that a principal needs permissions to both the secret and the specific key used to encrypt it, dramatically reducing the risk of unauthorized access.

Binadox Checklist:

• Audit all existing secrets in AWS Secrets Manager to identify those using the default AWS-managed key.
• Develop a CMK strategy, deciding whether to use a single key or multiple keys for different applications or data sensitivity levels.
• Create new CMKs with clearly defined key policies that grant administrative and usage permissions based on the principle of least privilege.
• Plan and execute a phased migration of existing secrets to CMK encryption, ensuring IAM policies for applications are updated with kms:Decrypt permissions.
• Implement preventative guardrails, such as IaC policies, to ensure all future secrets are created using a CMK.
• Configure automated key rotation on your CMKs to meet internal and external compliance requirements.

Binadox KPIs to Track:

• Percentage of secrets encrypted with Customer-Managed Keys.
• Mean Time to Remediate (MTTR) for secrets found using the default encryption key.
• Number of successful automated key rotations per quarter.
• Reduction in security findings related to improper secret management during audits.

Binadox Common Pitfalls:

• Migrating a secret to a CMK without updating the corresponding application’s IAM role to include kms:Decrypt permissions for the new key, causing application failure.
• Creating overly permissive key policies that grant decryption access to broad groups, negating the security benefits of using a CMK.
• Failing to plan for multi-account architectures, which require CMKs for cross-account secret sharing.
• Lacking a defined key lifecycle management process, leading to unused keys that still incur costs or keys that are not rotated according to policy.

Conclusion

Transitioning from default AWS-managed keys to Customer-Managed Keys in AWS Secrets Manager is a critical step in maturing your cloud security and governance framework. While it requires an initial investment in planning and configuration, the benefits—including granular access control, improved incident response capabilities, and streamlined compliance—are essential for protecting your most sensitive credentials.

By implementing the guardrails and operational practices outlined in this article, you can systematically eliminate this common security gap. Start by auditing your current environment to understand your exposure, and then build a roadmap to ensure every critical secret is protected by a key that you control.