Lesson 353 · AWS Learning Path

AWS 353: Secure handling of parameters, secrets, artifacts, and temporary credentials

Anil Jalela · Published Jun 13, 2026 · 7 min read

Why this lesson matters

Delivery pipelines handle values with very different lifecycles: ordinary configuration, sensitive secrets, temporary AWS credentials, source archives, build artifacts, signatures, reports, and logs. Treating all of them as “environment variables” creates leakage, excessive privilege, stale credentials, and irreproducible releases.

This lesson starts with classification and data flow. Service selection follows ownership, retrieval pattern, rotation, authorization, encryption, audit, retention, and compromise response.

Outcomes

You will be able to:

• classify configuration, identifiers, secrets, credentials, keys, and artifacts;
• select Parameter Store, Secrets Manager, KMS, S3, CodeArtifact, and runtime roles by lifecycle;
• explain envelope encryption and the separate service/IAM/KMS authorization paths;
• prevent exposure through Git, arguments, environment, process inspection, logs, caches, artifacts, and test fixtures;
• use temporary workload identity and federation instead of static CI keys;
• design rotation, revocation, version pinning, provenance, retention, and incident response;
• test denied paths and prove redaction without displaying a real secret.

Classify before storing

A parameter name, secret name, tag, description, ARN, and error message can reveal business context even when the value is encrypted. Classification includes metadata.

Service decision boundaries

Systems Manager Parameter Store

Use for hierarchical configuration and, where appropriate, SecureString values with KMS. Consider standard/advanced tier capabilities and cost, version/label behavior, throughput, policies, and change notification needs. A SecureString is not a complete rotation system.

Secrets Manager

Use when secret lifecycle, versions/stages, managed rotation patterns, cross-account policy, replication, or secret-specific audit and retrieval are valuable. Rotation must update the real target credential and validate both sides; changing only the stored value breaks clients.

KMS

KMS protects keys and cryptographic operations. It is not a general secret database. Envelope encryption uses a KMS key to protect a data key, while the application/service encrypts data with the data key. Authorization may require IAM/resource policy plus key policy/grant; an allow in one layer cannot defeat explicit deny in another.

S3 and CodeArtifact

Use S3 for versioned release bundles, manifests, reports, and attestations with restricted access, encryption, object ownership, retention, and lifecycle. Use CodeArtifact for supported package formats, repositories, upstreams, and package-version lifecycle. Neither proves artifact trust by storage alone; bind digest, source revision, build identity, dependencies, and test evidence.

Workload identity

Use an IAM role attached to EC2/ECS/Lambda, EKS pod identity or approved web-identity federation, CodeBuild service role, or external CI OIDC federation. The workload receives temporary credentials. Avoid creating IAM user access keys for CI.

End-to-end data-flow review

For each sensitive value, draw:

authoritative owner -> encrypted store -> retrieval identity
 -> process memory -> downstream authentication/use
 -> logs/cache/artifact risk -> rotation/revocation -> audit evidence

Record who can create, update, read, rotate, delete, replicate, decrypt, grant access, and change the workload role. Separate secret administrators from secret consumers where risk requires it. A principal able to change both workload code and its role can often obtain the secret indirectly.

Exposure surfaces

Source and history

.gitignore does not remove committed history. If a real credential enters Git, revoke/rotate first, preserve incident evidence, determine exposure and clones, then coordinate history remediation. Never rely on deleting the latest line.

Arguments and shell

Command-line arguments may appear in history, process listings, CI logs, and audit tools. Avoid --password value. Read from a protected descriptor/file, native service integration, or SDK response directly into process memory. Disable tracing before retrieval.

Environment

Environment variables are convenient but may leak through child processes, debug dumps, platform inspection, or crash reports. Use them for identifiers or short-lived injection only after threat review; never print the full environment.

Logs and exceptions

Use an allowlist of safe fields rather than regex-only redaction after serialization. Do not log request headers, presigned URLs, secret responses, session tokens, or raw SDK exceptions without inspection. Request ID and error code are normally enough for correlation.

Caches and artifacts

CI caches and artifacts survive the process and can cross branches/jobs. Cache dependencies by validated key, not credentials or decrypted configuration. Inspect archive file lists and sample content before upload. Set retention and access explicitly.

Local canary-redaction test

Use a fake value that is unmistakable but has no real privilege:

canary='TRAINING_SECRET_CANARY_7f3a'
mkdir -p evidence artifact
printf 'safe build output\n' > artifact/result.txt
printf 'level=INFO event=test_complete token=[REDACTED]\n' > evidence/run.log

if rg -n --fixed-strings "$canary" . --glob '!.git/**'; then
  printf 'canary leaked\n' >&2
  exit 1
else
  printf 'canary absent from files\n'
fi

Also inspect process arguments and captured CI logs in an isolated test. Passing a canary scan does not prove no other secret exists; combine repository history scanning, allowlisted logging, artifact inspection, and least privilege.

Secure retrieval pattern

The application should retrieve only the named secret/parameter it needs, in an approved Region/account, using its workload role. Parse the value without printing it, validate schema, use it, and discard references as soon as practical.

For Secrets Manager encrypted with a customer-managed KMS key, reason about secretsmanager:GetSecretValue, resource policy if cross-account, key policy/IAM authorization for decrypt through the service, explicit denies, and conditions such as kms:ViaService and encryption context. The secret value is encrypted; name, description, tags, rotation settings, and KMS ARN are metadata.

Caching reduces API calls and latency but increases how long an old or compromised value remains in memory. Define TTL, rotation overlap, invalidation, and behavior when retrieval fails. Never continue indefinitely with an expired credential merely for availability.

Artifact trust and promotion

Build once, then promote the same immutable digest through environments. A release manifest should include source commit/tag, clean-tree state, dependency lock/SBOM, builder identity, build time, toolchain, tests, artifact digest, signature/attestation reference, and approval.

Encryption protects confidentiality, a digest detects accidental or malicious content change when the expected digest is trusted, a signature/attestation identifies a signing/building identity under a policy, and review establishes human authorization. None substitutes for the others.

Avoid rebuilding for production because the source, dependency registry, base image, compiler, clock, or build environment may have changed.

Rotation, revocation, and deletion

Design state transitions:

1. Create new credential/version.
2. Validate target accepts it.
3. Mark/promote the new version for consumers.
4. Allow bounded overlap if protocol requires it.
5. Verify consumers migrated and errors are normal.
6. Revoke old credential.
7. Monitor and retain audit evidence.

For alternating-user rotation, understand which database/user privileges exist in both states. For single-user rotation, plan brief inconsistency and failed rollback. Deletion needs recovery window, dependency proof, retention/legal approval, and owner authorization. KMS-key deletion can make dependent ciphertext unrecoverable.

Failure scenarios

Complete all eight:

1. CI log prints a bearer token.
2. Secret committed three weeks ago is deleted only from the latest commit.
3. Rotation updates Secrets Manager but not the database.
4. Workload role can read every secret under a broad wildcard.
5. Cross-account read has secret-policy allow but KMS deny.
6. Cache serves old credentials after rotation.
7. A build artifact contains .env and debug dumps.
8. OIDC trust accepts repositories/branches beyond the intended workflow.

For each record detection, containment, rotation/revocation, evidence preservation, blast radius, root cause, control correction, owner, and retest. Never paste the compromised value into the ticket.

Independent challenge and acceptance

Produce a classification inventory, six-value data flows, service decision matrix, least-privilege retrieval design, OIDC/workload-role trust conditions, canary tests, rotation state machine, immutable artifact manifest, eight incident records, retention/deletion policy, and residual-risk register.

Pass requires zero real credentials in source/history/log/artifact, short-lived workload identity, explicit Region/account/secret scope, independent KMS reasoning, default-redacted diagnostics, digest-bound promotion, tested rotation failure, and a documented revocation path.

Official sources

• Secrets Manager best practices
• Secrets Manager encryption and decryption
• Parameter Store
• Temporary credentials
• CodeBuild data protection
• CodeArtifact