Cloud Secrets, Storage and Key Management
S3 and cross-cloud storage policy, Terraform state, Azure Key Vault, SAS tokens, HashiCorp Vault and KMS: who can read, decrypt and sign.
A secret store is only as good as the policy in front of it, and several of the surfaces below hand out authorization inside a URL or a state file nobody treats as sensitive.
Terraform State
The file Terraform uses to remember infrastructure may contain values you would never place in a public repository. Terraform state records resource attributes and may contain recoverable sensitive values even when the source variable was marked sensitive. Remote backends such as S3, Azure Storage and Terraform Cloud become high-value assets. ACLs, encryption and locking belong in the threat model. I search for local tfstate, backend configuration, Git history and remote storage permissions. Then I identify which secrets are actually present. Marking an output sensitive hides display in some contexts. It does not remove the value from state when the provider needs to persist that attribute.
1
2
find . -name '*.tfstate*' -o -name '.terraform'
terraform show -json terraform.tfstate | jq '.'
S3
A private bucket may still be exposed through policies, roles, presigned URLs or an application that signs requests too broadly. S3 authorization combines IAM, bucket policies, access points and public-access controls. Legacy ACLs still exist in some environments. ListBucket, GetObject and PutObject are different capabilities. Presigned URLs inherit the permissions of the signer and expire according to their signature. I identify principal, bucket region, policy and allowed operations before downloading objects. In white-box work, Access Analyzer helps map exposure. Block Public Access reduces many dangerous public configurations but does not fix an overprivileged internal role or a presigned URL for a sensitive object.
1
2
aws s3api get-bucket-policy --bucket lab-bucket
aws s3 ls s3://lab-bucket
Azure Key Vault
Key Vault can be configured correctly and still return a credential far more powerful than the identity used to read the secret. Key Vault stores secrets, keys and certificates. Authorization may use Azure RBAC or legacy access policies. Data plane and management plane are different. Managing a vault does not automatically mean reading secrets and the reverse also applies. I identify the authorization model, role assignments, network restrictions and which objects the principal can get, list or use for signing. The impact of reading a secret depends on what it authenticates to. Connection strings, certificates and API tokens need to be followed to the final system.
1
2
az keyvault list
az keyvault secret list --vault-name lab-vault
Cloud Storage Misconfigurations Across AWS, Azure and GCP
A public bucket is only the most obvious form of exposure. Shared URLs, internal identities and cross-account policies are often more interesting. S3, Azure Blob and GCS use different policy, ACL, shared-access and public-access-prevention models. List, read, write and delete are separate capabilities. Upload into storage consumed by an application may create a supply-chain path. I identify provider, container, principal and allowed operation before copying data. Write tests use a canary object. Anonymous read and authenticated read should be distinguished. A signed URL is also a temporary credential and needs proper scope and lifetime.
1
2
3
aws s3 ls s3://lab-bucket
az storage blob list --container-name lab --account-name labstorage
gcloud storage ls gs://lab-bucket
Azure Storage SAS Tokens
A SAS token can turn a URL into a credential that can read, write or list data until it expires. Shared Access Signatures carry scope, permissions, start time, expiry and signature. Account SAS, service SAS and user delegation SAS use different models. A token leaked through logs, tickets or browser history may be reused by whoever obtains it during its lifetime. I decode the query, identify sp, se and sr and test only operations explicitly authorized. User delegation SAS reduces dependence on account keys. Stored access policies support revocation in some models. Short lifetimes reduce exposure.
1
2
3
4
5
python3 - <<'PY2'
from urllib.parse import urlparse,parse_qs
u='https://acct.blob.core.windows.net/c/file?sp=r&se=...&sig=...'
print(parse_qs(urlparse(u).query))
PY2
HashiCorp Vault
Vault reduces static secrets, but a token with a broad policy remains a privileged identity concentrated in one place. Vault uses auth methods to create tokens and policies to control paths and capabilities. Secrets engines may generate dynamic credentials. Token accessors, orphan tokens, response wrapping, namespaces and leases change lifecycle and revocation. I identify the auth method, token policies, capabilities and mounts before listing or reading any secret. list and read are different capabilities. A secret path may be protected while metadata or mount discovery remains visible.
1
2
vault token lookup
vault token capabilities secret/data/app
KMS and Encryption Key Misconfigurations
Encryption at rest is only as strong as the key policy. If the wrong identity can call Decrypt, the ciphertext remains perfectly valid and perfectly accessible. Cloud KMS services separate key administration from key usage. Policies, grants and IAM define encrypt, decrypt, sign and policy changes. Envelope encryption means data keys are protected by a KMS key. Compromising decrypt permission may unlock many objects without extracting the master key. I map key policies, grants, aliases and principals with decrypt or sign rights before testing a canary ciphertext. A key administrator does not need decrypt permission in a good design. Separation of duties reduces impact from a compromised admin account.
1
aws kms get-key-policy --key-id <key-id> --policy-name default