Posts Tagged ‘SecretsManagement’
[AWSReInvent2025] Modern Secrets Management: Advancing from Traditional Practices to Security Frameworks Prepared for Artificial Intelligence
Lecturers
Resh Desai, Zach Miller, and Jake Farrell presented this session. Resh Desai works as a solutions architect at Amazon Web Services, driving forward developments in secrets management. Zach Miller is a Senior Worldwide Security Specialist Solutions Architect at AWS, specializing in cryptography, keys, secrets, and certificates. Jake Farrell serves as Senior Director of Engineering at Acquia, which provides open digital experience platforms.
Abstract
The presentation sheds light on the evolution of secrets management, highlighting AWS Secrets Manager as a central tool for handling the complete lifecycle of sensitive credentials. It weighs the advantages and drawbacks of centralized versus decentralized approaches, outlines key capabilities like encryption, automated rotation, cross-region replication, and high-volume retrieval, and details Acquia’s comprehensive migration efforts. In addition, it explores strategies for multi-tenant separation, patterns for Kubernetes integration, future synergies with agentic AI, and the latest service improvements that support third-party rotations and easier container-based deployments.
Core Functionalities of AWS Secrets Manager
AWS Secrets Manager provides a purpose-built service dedicated to managing the entire lifecycle of application secrets, database credentials, and API keys, setting it apart from IAM for identity management or KMS for cryptographic operations. By design, every secret undergoes envelope encryption with AWS-managed KMS keys, though users can opt for customer-managed keys to support scenarios such as cross-account sharing.
This setup integrates smoothly with CloudTrail to deliver thorough auditing of all actions, from creation and modification to deletion. Automation through Lambda enables rotation schedules that align precisely with enterprise policies, whether set at 30 or 90 days. For resilience, multi-region replication ensures secrets remain available during regional failovers. The service handles up to 10,000 transactions per second for retrieval, further enhanced by an open-source agent that implements caching with configurable time-to-live periods, thereby improving both efficiency and the overall developer experience.
Together, these features create a secure and traceable environment that integrates seamlessly with the wider AWS security landscape.
Navigating Centralized and Decentralized Deployment Choices
When designing secrets storage, architects must decide between consolidating secrets in a single dedicated account or distributing them closer to the applications that consume them. Centralized configurations often resonate with organizations in regulated sectors, as they allow for standardized practices in naming, tagging, and permission enforcement—typically achieved through enforced CI/CD pipelines or bespoke abstraction layers. Such consistency bolsters monitoring and control across the enterprise, although it requires significant initial investment in development and can introduce latency when adopting newly released capabilities.
On the other hand, a decentralized model empowers individual application teams to manage secrets directly via consoles or SDKs, offering greater adaptability to unique requirements. This approach streamlines onboarding and accommodates specialized needs more naturally, but it calls for robust supplementary governance to ensure alignment with broader standards.
In practice, the ideal configuration depends on factors like secret creation processes, ongoing management, replication demands, access patterns, and visibility needs, reflecting insights gathered from diverse customer experiences rather than a one-size-fits-all rule.
Acquia’s Migration Experience and Multi-Tenant Architecture
Acquia maintains oversight of over 300,000 distinct secret paths distributed across multiple AWS accounts, supporting millions of daily ephemeral pod instances and tens of thousands of hourly API interactions. Moving away from older systems required careful categorization of secrets into groups such as customer-supplied elements (including third-party tokens and environment variables), internal service communications, and emerging hybrid forms suited to AI agents.
To manage this complexity, Acquia developed a custom fronting API that applies type-specific rules for validation, scoping, and lifecycle policies, such as mandatory rotation or timed expiry. Rigorous least-privilege principles ensure complete separation between platform operations and customer data. For delivery into runtime environments, the organization relies on open-source components like the External Secrets Operator combined with AWS CSI drivers, which synchronize and inject secrets into Kubernetes as variables, configuration templates, or command-line flags. Strategic caching layers further reduce direct API calls, delivering noticeable gains in speed and expense control.
Through this disciplined, layered framework, Acquia achieves robust multi-tenancy while addressing gaps that IAM alone cannot fully cover in interconnected service scenarios.
Future Directions in Agentic AI Collaboration
Looking ahead, Acquia’s designs feature an AI gateway that provides a unified point for observing model invocations routed through Amazon Bedrock, complemented by a standardized factory for quickly provisioning secure agents. By embedding Secrets Manager deeply, the platform enables on-demand injection of properly scoped credentials, allowing smooth evolution alongside emerging AI features without compromising protective measures.
This ongoing partnership with AWS has yielded tangible benefits in operational streamlining, lower maintenance burdens, and enhanced overall performance.
Latest Service Developments and Their Wider Impact
Innovations continue to simplify adoption in container environments, with EKS add-ons now automating the installation and configuration of CSI drivers. The introduction of managed external secrets brings one-click rotation capabilities to external providers like Salesforce, removing the need for custom scripting and eliminating risks of desynchronization.
Native integrations now span more than 55 AWS services, making secret management largely invisible to end users. These progresses reduce entry barriers to advanced security practices, enabling teams to concentrate on innovation even as autonomous systems increase demands on privilege management.
In essence, effective secrets governance forms the bedrock of durable, expandable systems vital for both current operations and forthcoming intelligent workloads.
Links:
[SpringIO2023] Managing Spring Boot Application Secrets: Badr Nass Lahsen
In a compelling session at Spring I/O 2023, Badr Nass Lahsen, a DevSecOps expert at CyberArk, tackled the critical challenge of securing secrets in Spring Boot applications. With the rise of cloud-native architectures and Kubernetes, secrets like database credentials or API keys have become prime targets for attackers. Badr’s talk, enriched with demos and real-world insights, introduced CyberArk’s Conjur solution and various patterns to eliminate hard-coded credentials, enhance authentication, and streamline secrets management, fostering collaboration between developers and security teams.
The Growing Threat to Application Secrets
Badr opened with alarming statistics: in 2021, software supply chain attacks surged by 650%, with 71% of organizations experiencing such breaches. He cited the 2022 Uber attack, where a PowerShell script with hard-coded credentials enabled attackers to escalate privileges across AWS, Google Suite, and other systems. Using the SALSA threat model, Badr highlighted vulnerabilities like compromised source code (e.g., Okta’s leaked access token) and build processes (e.g., SolarWinds). These examples underscored the need to eliminate hard-coded secrets, which are difficult to rotate, track, or audit, and often exposed inadvertently. Badr advocated for “shifting security left,” integrating security from the design phase to mitigate risks early.
Introducing Application Identity Security
Badr introduced the concept of non-human identities, noting that machine identities (e.g., SSH keys, database credentials) outnumber human identities 45 to 1 in enterprises. These secrets, if compromised, grant attackers access to critical resources. To address this, Badr presented CyberArk’s Conjur, an open-source secrets management solution that authenticates workloads, enforces policies, and rotates credentials. He emphasized the “secret zero problem”—the initial secret needed at application startup—and proposed authenticators like JWT or certificate-based authentication to solve it. Conjur’s attribute-based access control (ABAC) ensures least privilege, enabling scalable, auditable workflows that balance developer autonomy and security requirements.
Patterns for Securing Spring Boot Applications
Through a series of demos using the Spring Pet Clinic application, Badr showcased five patterns for secrets management in Kubernetes. The API pattern integrates Conjur’s SDK, using Spring’s @Value annotations to inject secrets without changing developer workflows. The Secrets Provider pattern updates Kubernetes secrets from Conjur, minimizing code changes but offering less security. The Push-to-File pattern stores secrets in shared memory, updating application YAML files securely. The Summon pattern uses a process wrapper to inject secrets as environment variables, ideal for apps relying on such variables. Finally, the Secretless Broker pattern proxies connections to resources like MySQL, hiding secrets entirely from applications and developers. Badr demonstrated credential rotation with zero downtime using Spring Cloud Kubernetes, ensuring resilience for critical applications.
Enhancing Kubernetes Security and Auditing
Badr cautioned that Kubernetes secrets, being base64-encoded and unencrypted by default, are insecure without etcd encryption. He introduced KubeScan, an open-source tool to identify risky roles and permissions in clusters. His demos highlighted Conjur’s auditing capabilities, logging access to secrets and enabling security teams to track usage. By centralizing secrets management, Conjur eliminates “security islands” created by disparate tools like AWS Secrets Manager or Azure Key Vault, ensuring compliance and visibility. Badr stressed the need for a federated governance model to manage secrets across diverse technologies, empowering developers while maintaining robust security controls.