More Ways to Secure Secrets

In my previous post, we explored foundational approaches to secret storage – file systems, environment variables, and hardware security modules. While these methods form the basis of many security strategies, they all share a common limitation: they rely on static credentials that must be carefully protected and regularly rotated.

But what if you could eliminate static secrets entirely? What if credentials could exist only when needed, automatically expire, and never require manual rotation? Modern cloud-native architectures have evolved beyond traditional secret storage to embrace dynamic, identity-based approaches that fundamentally change how we think about credentials.

In this post, I’ll explore three additional techniques that help secure your secrets and reduce your attack surface.

Federated identity

Federated identities using JWT authentication/OIDC enable passwordless authentication through federated trust relationships. Instead of storing static credentials, systems exchange short-lived tokens based on verifiable identity claims. Both systems must be configured to trust each other, eliminating the need for shared secrets.

Strengths

• Based on cryptographically signed tokens with no static secrets to rotate
• Short-lived tokens minimize exposure windows
• Supports fine-grained authorization through claims validation
• Enables zero-trust security models
• Works across different platforms and cloud providers
• Supports conditional access policies, logging, and monitoring

Weaknesses

• Requires trust relationship configuration between systems
• Signing systems must be secured to prevent token forgery
• May require application code changes
• You must implement claim validation correctly and evaluate appropriate claims
• Requires HTTPS endpoints on both sides for validation and token exchange

Common exploitation techniques

Attackers target federated credentials through:

• Token theft: Stealing tokens from memory or local storage
• Claim manipulation: Exploiting improper validation of token claims (such as validating the issuer against a wildcard)
• Endpoint manipulation: Compromising the endpoint to alter supported claims or keys
• Signing key compromise: Gaining access to the private keys used to sign tokens, enabling request forgery
• Cryptographic vulnerabilities: Exploiting weak algorithms and misconfigurations in the HTTPS configuration (weak ciphers, outdated TLS/SSL versions, etc.)

Hardening strategies

To secure these implementations:

• Both systems must use strong HTTPS configurations and be isolated from untrusted code
• Use short token lifetimes (minutes, not hours or days)
• Carefully validate claims
• Store tokens in memory only, never in logs or on disk
• Use mutual TLS (mTLS) for additional transport security when available
• Avoid validating against wildcard issuers or audiences
• Properly secure and monitor the web endpoints used for token exchange (this includes using WAFs, rate limiting, and logging)

When properly implemented with infrastructure-based identities, this approach eliminates static credentials entirely. That said, once a token is issued, it must still be protected in memory to prevent theft or misuse.

Infrastructure-based secrets

Infrastructure-based secret management leverages the platform itself to provide credentials transparently or semi-transparently. Examples include managed identities in Azure, IAM roles in AWS, and service accounts in Google Cloud. These systems allow the system to use an assigned identity to access other resources without needing to directly manage static credentials.

Generally, these systems rely on federated identity and tokens (using a metadata service at a known address, such as https://169.254.169.254/metadata or https://169.254.169.254/latest/meta-data). Often, tooling handles the token exchange and management for you. Because the exchange uses a local connection to the well-known address, the entire system has the ability to request and receive tokens for the assigned identity.

Strengths

• No static secrets to manage or rotate
• Credentials are short-lived and automatically rotated
• Access is restricted to code running on specific infrastructure or services
• Platform enforces authentication and authorization
• Integrates seamlessly with cloud services and supporting code

Weaknesses

• Any process running on the infrastructure can potentially access the identity
• Root or privileged users and processes can still impersonate the identity
• May require application code changes to support
• May require a secondary secret provider for local development, increasing the attack surface
• Deployment to the system grants access, so you must properly secure the deployment process, the items being deployed, and the infrastructure environment

Common exploitation techniques

Attackers exploit infrastructure-based secrets by:

• Instance metadata service (IMDS) attacks: Accessing cloud metadata endpoints (e.g., http://169.254.169.254/) to discover details about the system or generate tokens
• Privilege escalation: Gaining elevated permissions to assume higher-privileged identities
• Lateral movement: Using compromised instances to access resources or additional systems
• Misconfigured policies: Exploiting overly permissive IAM policies or role assignments, including wildcard permissions

Hardening strategies

To secure infrastructure-based secret access:

• Rely on the cloud provider’s implementation and best practices
• Apply least privilege principles to permission assignments
• Use infrastructure-as-code to ensure the system is deployed consistently
• Secure deployment pipelines to prevent unauthorized code deployment
• Monitor for unexpected processes and access patterns
• Implement network segmentation to limit blast radius
• Restrict network access for processes or users to minimize exposure

Infrastructure-based secrets are a significant security improvement over static credentials, but they’re only as secure as the infrastructure configuration and access policies you implement.

Secret vaults and key management systems

Dedicated secret management systems like HashiCorp Vault, Azure Key Vault, AWS Secrets Manager, and Google Secret Manager provide centralized, auditable secret storage with fine-grained access control. These systems generally use encryption keys stored in HSMs to protect secrets at rest and HTTPS to protect them in transit.

Strengths

• Centralized management and auditing of all secrets
• Fine-grained access control with detailed policies
• Comprehensive audit logs of all access attempts
• Support for secret versioning and rotation
• Supports secret sharing across environments

Weaknesses

• Adds complexity and operational overhead
• Represents a single point of failure if not properly designed
• Represents a single point of access for multiple secrets
• Initial authentication requires a credential
• May introduce latency
• Generally requires application code changes to integrate (an obvious exception being Azure App Services or solutions with built-in vault integration)
• You must rotate stored secrets regularly
• Secrets are decrypted in application memory after retrieval

Common exploitation techniques

Attackers target vault systems through:

• Bootstrap credential theft: Stealing the initial credentials used to authenticate with the vault
• Process compromise: Stealing secrets from application memory or environment variables after retrieval
• Policy exploitation: Overly permissive vault policies (or reused credentials) grant access to the vault contents

Hardening strategies

To secure vault-based secret management:

• Use infrastructure-based authentication (managed identities) to access vaults when possible
• Use separate vault instances for different security zones (if you wouldn’t want a given client or instance to see all of the secrets in a vault, use separate vaults)
• Carefully protect (or locally encrypt) retrieved credentials and ensure they’re masked in logs
• Implement secret versioning and rotation policies
• Regularly audit and review vault policies and access patterns

Vaults significantly improve secret security, but remember: you’re still passing secrets to your application. The security depends on how you grant vault access and how you protect those credentials after retrieval.

Choosing the right approach

There’s no single best method for storing and accessing secrets. The appropriate choice depends on your security requirements, infrastructure, compliance needs, and operational capabilities. In practice, you’ll typically use a combination of these approaches to balance security and usability. Now that you know some of the options, the next post will show you how to combine them into a layered strategy.