Unravel โบ Java concepts โบ Cloud and operations
Cloud credentials and secrets management
Code that calls cloud services needs credentials, and database passwords and API keys need a safe home.
At a glance
A hotel keycard instead of a copied house key.
- 1A credentials provider chain (DefaultCredentialsProvider, DefaultAzureCredential, Application Default Credentials) tries environment variables, config files and finally the identity of the running machine or pod (instance profile, managed identity, workload identity)
- 2Secret stores (AWS Secrets Manager, Parameter Store, Azure Key Vault, Google Secret Manager, HashiCorp Vault) hold passwordsThe app reads them at startup with getSecretValue, usually via Spring config import so they appear as properties.
- 3Assuming a role (AssumeRole) trades the base identity for temporary credentials with narrower permissions for a task
- 4Rotation replaces secrets on a schedule; the app must re-read or reconnect, not cache a password forever
- StaticCredentialsProvider with a literal access key in code is the textbook leak: it ends up in Git history and logs
- Do not log secrets or put them in exception messages, and avoid passing them as command-line arguments (visible in process lists)
- On cloud VMs and pods, a local metadata endpoint (for example 169.254.169.254) or a projected token file returns temporary credentials for the attached identity
SecretsManagerClient secrets = SecretsManagerClient.create();String json = secrets.getSecretValue(GetSecretValueRequest.builder().secretId("prod/orders/db").build()) .secretString();DbCredentials creds = mapper.readValue(json, DbCredentials.class);- line 1 uses SecretsManagerClient, the core of Cloud credentials and secrets management
- line 2 uses GetSecretValueRequest, the core of Cloud credentials and secrets management
Read the full explanation (about 2 min)
Code that calls cloud services needs credentials, and database passwords and API keys need a safe home. The modern approach is short-lived identities supplied by the platform and secrets fetched at runtime from a secret store, never written in code or images.
A mental model
A hotel keycard instead of a copied house key. The card is issued for your stay, only opens your room and expires on its own; a lost one is cancelled without changing any locks.
How it works
A credentials provider chain (DefaultCredentialsProvider, DefaultAzureCredential, Application Default Credentials) tries environment variables, config files and finally the identity of the running machine or pod (instance profile, managed identity, workload identity).
Secret stores (AWS Secrets Manager, Parameter Store, Azure Key Vault, Google Secret Manager, HashiCorp Vault) hold passwords. The app reads them at startup with getSecretValue, usually via Spring config import so they appear as properties.
Assuming a role (AssumeRole) trades the base identity for temporary credentials with narrower permissions for a task.
Rotation replaces secrets on a schedule; the app must re-read or reconnect, not cache a password forever.
Going deeper
StaticCredentialsProvider with a literal access key in code is the textbook leak: it ends up in Git history and logs. Use the default chain and give the workload an IAM role with least privilege.
Do not log secrets or put them in exception messages, and avoid passing them as command-line arguments (visible in process lists).
Fetching a secret on every request makes the secret store a hot dependency and adds cost and latency. Cache for a short time and handle rotation by refreshing on authentication failure.
Under the hood
On cloud VMs and pods, a local metadata endpoint (for example 169.254.169.254) or a projected token file returns temporary credentials for the attached identity. SDK providers call it, cache the result, and refresh before expiry, signing each API request with the resulting short-lived keys.
Common mistakes
- Hard-coded access keys or passwords.
- Over-broad roles (administrator access).
- Logging secrets.
- Caching secrets forever so rotation breaks the app.
How Unravel recognises it
When you paste code, Unravel looks for these signs of cloud credentials and secrets management. Spotting them yourself is a good habit when you read unfamiliar code:
- Annotations:
@VaultPropertySource - Types:
SecretsManagerClientGetSecretValueRequestSsmClientGetParameterRequestSecretManagerServiceClientSecretClientSecretClientBuilderVaultTemplateVaultOperationsDefaultCredentialsProviderDefaultAzureCredentialDefaultAzureCredentialBuilderGoogleCredentialsStsClientand 10 more
Part of a learning path
- Cloud-native Java ยท previous: Containers and Kubernetes in Java code ยท next: Object storage SDKs (S3, Azure Blob, GCS)
Related concepts
Frequently asked questions
What is Cloud credentials and secrets management?
Code that calls cloud services needs credentials, and database passwords and API keys need a safe home. The modern approach is short-lived identities supplied by the platform and secrets fetched at runtime from a secret store, never written in code or images.
What are the most common mistakes with Cloud credentials and secrets management?
Hard-coded access keys or passwords. Over-broad roles (administrator access). Logging secrets. Caching secrets forever so rotation breaks the app.
How can I see Cloud credentials and secrets management in real code?
Paste your own Java into Unravel and it will point out where cloud credentials and secrets management appears, explain how it works at the detail level you choose, and draw the flow of the code around it.