AWS adds workload credentials provider for cert and secret delivery

AWS introduced AWS Workload Credentials Provider, an open source client service that gives applications a local path for certificates and secrets from AWS Secrets Manager and AWS Certificate Manager.

The provider targets a familiar operations problem: teams store secrets and certificates in managed cloud services, then write their own scripts to fetch them, cache them, place them on disk, and reload NGINX, Apache, or another dependent service before a certificate expires. AWS now offers a first-party agent for that client-side work.

AWS designed the tool for workloads on AWS, in data centers, and in other environments. That matters for teams that run hybrid estates but already use AWS for certificate issuance or secret storage. A service on an EC2 instance, a Windows server, or an on-premises Linux host can consume the same managed sources without a full move to an AWS runtime.

Developers configure the provider with a TOML file. That file defines certificate ARNs, IAM role ARNs, output paths for certificate material, private key files, certificate chains, refresh commands, logging, and runtime behavior. The provider then retrieves the configured material, writes files with restricted permissions, and refreshes the local copy when AWS reports a content change.

AWS says the provider supports ACM certificate export for public and private TLS certificates. That gives architects another option for web servers and service endpoints that need file-based TLS assets, including stacks that cannot call AWS APIs inside the request path.

Secrets Manager support extends the older AWS Secrets Manager Agent model. Teams that already deployed that agent can view Workload Credentials Provider as the broader successor path, since AWS has framed the new project around both secrets and certificates.

The provider checks configured certificates every 24 hours. It also runs an initial refresh at startup, spreads refresh timing across hosts to avoid request spikes, and lets operators reload configuration without reinstalling the service. Teams can configure up to 50 certificates, and the provider manages each certificate in its own process.

That process model gives operators a useful blast-radius boundary. A failure in one certificate workflow should not stop the provider from managing another certificate on the same host. Teams that run multi-tenant servers or shared gateways will care about that isolation.

The reload command closes the gap between certificate rotation and application use. A provider can write a new certificate to /etc/pki/tls/certs/example.com.crt, write the key to /etc/pki/tls/private/example.com.key, update the chain file, and run /usr/sbin/nginx -s reload. Operators no longer need a separate cron job that guesses when ACM changed a certificate.

Linux deployments require systemd. Windows deployments require PowerShell 5.1 or later. AWS runs the service under a low-privilege user, which fits the pattern security teams want for local credential agents: give the agent the minimum host permissions it needs to write files and trigger a bounded reload command.

The architecture will appeal to teams that use file-oriented software. Web servers, legacy Java services, service meshes with file watchers, and off-the-shelf appliances often expect a certificate and key on disk. Developers can change application code to call Secrets Manager or ACM APIs, but many operations teams prefer to keep credentials out of the app runtime and let a host service handle retrieval and rotation.

The provider also gives AWS customers a native answer to a pattern many teams solved with Vault Agent. HashiCorp Vault Agent can authenticate, cache, render templates, and renew credentials for local applications. AWS now covers a similar client-side role for customers that keep their source of record in Secrets Manager and ACM.

That comparison has limits. Vault supports a wider identity and secret ecosystem, including dynamic database credentials, many auth methods, and template rendering across providers. Workload Credentials Provider makes more sense when a team has committed to AWS managed services and wants fewer moving parts on the host.

Pricing follows the underlying services. AWS does not charge for the provider itself, and AWS released the project under the Apache 2.0 license. Teams still pay for Secrets Manager, ACM features, API usage, and any related infrastructure. Caching can reduce request volume, but architects should model Secrets Manager calls across fleets with many hosts and frequent restarts.

Security teams should review the IAM role design before they roll out the provider. The host needs permission to export specific certificates or read specific secrets. Broad read access would recreate the risk that central secret stores aim to reduce. A cleaner model gives each workload access to only the certificate ARNs and secret ARNs it needs.

Operators should also treat local files as sensitive assets. The provider can write certificate keys with restricted permissions, but host compromise still exposes files on disk. Teams should pair the tool with disk encryption, host hardening, audit logs, and strict controls around the reload command.

The most practical use case starts with TLS renewal. A team running NGINX on EC2 can issue a certificate in ACM, configure the provider to export it, place the certificate and key in the paths NGINX already uses, and reload NGINX after a refresh. The application stack keeps its current TLS layout, while AWS takes over certificate issuance and the provider handles local delivery.

A second use case fits hybrid applications. A company may run a database proxy or internal API gateway in a private data center while storing secrets in AWS. Workload Credentials Provider lets that host consume AWS-managed credentials without adding a custom sync service.

A third use case fits migration programs. Teams can move secret storage to AWS first, then change application code later. The provider bridges the old file-based contract and the new managed secret backend, which gives platform teams a lower-risk migration path.

Architects should still decide whether local files suit the workload. For new cloud-native services, direct SDK calls or workload identity can avoid writing long-lived material to disk. For software that already expects files, the provider reduces custom code and gives operators a managed refresh loop.

AWS has also given platform teams a governance hook. Central teams can standardize on ACM and Secrets Manager, publish a provider configuration pattern, and let application teams consume local files without learning the full AWS API surface. That helps in estates where operations teams own hosts and application teams own deployable services.

The trade-off sits in the control plane. Teams gain an AWS-supported path for local delivery, but they also tie more of the credential lifecycle to AWS APIs, IAM policies, and regional service behavior. Multi-cloud teams should test failure modes: stale cache behavior, startup during AWS API disruption, certificate export errors, and service reload failures.

Workload Credentials Provider will not remove the need for credential architecture. It narrows one troublesome part of it. Teams that already depend on Secrets Manager and ACM can replace brittle renewal scripts with a service that AWS maintains, then spend their review time on access boundaries, host controls, and rollout safety.

AWS has published the project on GitHub at aws/aws-workload-credentials-provider. Teams evaluating it should read the project documentation, confirm ACM export support for their certificate types, and test refresh and reload behavior against the exact services they run in production.