API Keys and Secrets Management in the Cloud

What counts as a secret and where secrets leak

A secret is any value that grants access or proves identity: cloud access keys, provider API tokens, database connection strings, OAuth client secrets, SMTP passwords, private keys, and encryption keys. Configuration such as a region name or a feature flag is not a secret and should not be handled like one, because mixing the two makes the real secrets harder to track.

Secrets leak through predictable paths. A .env file or a hard coded token committed to Git, including in the history of a branch that was later cleaned. A container image with a credential baked in at build time. A CI log that echoed the environment. A screenshot or a support ticket. A shared spreadsheet of “team logins”. Each of these is solved by the same rule: the secret lives in one managed store, and everything else fetches it from there at the moment of use.

The provider secret stores

AWS Secrets Manager stores a secret as versioned JSON or text, controls access through IAM resource policies, encrypts with a KMS key, and can rotate database credentials automatically on a schedule by running a Lambda function. It is priced per secret per month plus API calls, so teams with many low sensitivity settings often keep those in Systems Manager Parameter Store, which offers encrypted SecureString parameters at lower cost with the same IAM control.

Google Secret Manager holds secret versions with per secret IAM bindings, optional customer managed encryption keys, and automatic or user chosen replication across regions. It can publish a Pub/Sub message on a rotation schedule so your own code performs the rotation, and Cloud Run, Cloud Functions, and GKE can mount a secret directly as an environment variable or file.

Azure Key Vault stores secrets, cryptographic keys, and certificates in one service. Access is granted through Azure RBAC or vault access policies, and applications reach it with a managed identity so no bootstrap credential is needed. Soft delete and purge protection stop an accidental or malicious deletion from being final, and diagnostic logs record every read.

API tokens on Vultr, Linode, and other VPS providers

VPS providers do not offer a hosted secret manager, but their own API tokens still need care because a token can create, destroy, and reimage every server in the account. Vultr issues API keys from the account settings and lets you restrict the addresses allowed to use the API, so a key stolen from a laptop cannot be used from elsewhere. Linode issues personal access tokens with a scope per product area, such as read only for Linodes and no access to account billing, and each token can carry an expiry date. Create a separate token for every tool and pipeline, name it after that use, and keep the permissions to the minimum the job needs.

For the application secrets that live on the servers themselves, use a tool rather than a text file: HashiCorp Vault or OpenBao self hosted, or encrypted files with SOPS and age that are decrypted at deploy time by a key held only on the target server and in the CI secret store. A single VPS running Vault is a reasonable starting point for a small team, provided its own root token and unseal keys are stored offline.

Getting secrets to the application

The best delivery is no delivery: an application running on EC2, Lambda, Cloud Run, or an Azure VM should use the attached role, service account, or managed identity to fetch secrets at start up, so the only credential involved is one the platform issues and rotates itself. Where a static value is unavoidable, inject it as an environment variable at deploy time from the secret store or the CI platform’s encrypted variables, and never write it into the image, the repository, or a config file that is copied between machines.

• Fetch secrets at start up or on a cache timer, not on every request, and handle a fetch failure by refusing to start rather than falling back to a default.
• Keep production, staging, and development secrets in separate stores or paths with separate permissions.
• Add .env and credential file patterns to the global Git ignore list on every developer machine.
• Mask secret values in CI logs and disable debug output that prints environment variables.
• Give each service its own credential so a leak points to one place and revocation affects one thing.

Rotation, detection, and response

Rotate on a schedule that matches the blast radius: cloud access keys and provider tokens more often than a low value webhook secret, and everything immediately after a suspected exposure or a departure from the team. Rotation is only painless if the application reads the secret from the store rather than from a value pasted into it, which is another argument for the delivery model above. AWS shows the last used date of every access key in IAM, and Linode and Vultr show token creation dates, so unused credentials can be found and deleted.

Scan for leaks before they reach a remote. Tools such as gitleaks and trufflehog run as a pre commit hook and in CI, and GitHub’s secret scanning with push protection blocks a push that contains a recognised token format. AWS monitors public repositories for its own key formats and, on a match, applies a quarantine policy to the key and opens a support case; treat that notice as an incident, not a warning.

The audit trail that shows what a leaked key did is the subject of cloud audit logs explained.

Where to go next

Secret handling starts the day an account is opened. The marketplace lists AWS accounts, where Secrets Manager and IAM roles are available from the first login, along with Vultr accounts and Linode accounts, whose API tokens should be scoped and named before the first server is created.

Two related guides cover the rest of the picture: cloud account security essentials for MFA and root account protection, and SSH keys for cloud servers for the one credential this guide does not cover. The Cloud Library hub lists every security guide.