Tutorials

End-to-End AWS Credential Rotation with CoreLink

Time: 10 minutes Difficulty: Beginner Tools: Web UI, AWS CLI
Outcome. By the end of this tutorial you'll have an AWS IAM access key that CoreLink rotates automatically — new keys issued, old keys deleted from AWS, consumers picking up the new values from CoreLink with zero application downtime.

Prerequisites

Step 1 — Create an AWS IAM user for rotation

We'll rotate credentials for a real IAM user. First, create one:

aws iam create-user --user-name corelink-demo-app
aws iam create-access-key --user-name corelink-demo-app

Copy the AccessKeyId and SecretAccessKey values from the second command — you'll paste them into CoreLink in Step 3.

Step 2 — Grant CoreLink permission to rotate

CoreLink needs to be able to create and delete access keys for this user. Attach an inline policy:

cat > rotation-policy.json <<EOF
{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Action": ["iam:CreateAccessKey", "iam:DeleteAccessKey", "iam:ListAccessKeys"],
    "Resource": "arn:aws:iam::*:user/corelink-demo-app"
  }]
}
EOF

aws iam put-user-policy \
  --user-name corelink-demo-app \
  --policy-name corelink-self-rotate \
  --policy-document file://rotation-policy.json

Self-rotation (the user has permission to rotate its own keys) is the simplest setup. For production, use a dedicated rotation role that CoreLink assumes. Covered in the rotation use case.

Step 3 — Store the bootstrap credential in CoreLink

In the UI: Secrets → New Secret. Fill in:

Save. CoreLink writes the envelope-encrypted credential to storage; plaintext never touches disk.

Step 4 — Configure the rotation provider

Still in the secret detail view, click the Rotation tab → Configure Rotation:

Save. The scheduler now tracks this secret.

Step 5 — Trigger an on-demand rotation

Don't wait 30 days to see it work. Click Rotate Now in the UI. You'll see an event timeline:

2026-04-24 14:45:01  Rotation requested (user: [email protected])
2026-04-24 14:45:02  Provider: aws-iam
2026-04-24 14:45:03  Listing existing keys for corelink-demo-app... (1 found)
2026-04-24 14:45:04  Creating new access key...
2026-04-24 14:45:05  New key active: AKIA...XYZ (encrypted and stored as version 2)
2026-04-24 14:45:10  Grace period: 5 minutes (old key valid until 14:50:10)
2026-04-24 14:50:11  Deleting old key AKIA...ABC
2026-04-24 14:50:12  Rotation complete. Secret version 2 is current.

Step 6 — Verify

Confirm the new key is active in AWS:

aws iam list-access-keys --user-name corelink-demo-app
# {
#   "AccessKeyMetadata": [
#     { "UserName": "corelink-demo-app", "AccessKeyId": "AKIA...XYZ", "Status": "Active", "CreateDate": "2026-04-24T14:45:04+00:00" }
#   ]
# }

Only the new key exists; the old one is gone. From the CLI, fetch the current secret:

tbcl-cli secrets get aws-demo-app-key --format json
# {
#   "access_key_id": "AKIA...XYZ",
#   "secret_access_key": "wJalr...",
#   "version": 2,
#   "rotated_at": "2026-04-24T14:45:05Z"
# }

That's round-trip confirmation. The rotation provider swapped the key in AWS, updated the envelope-encrypted secret in CoreLink, and the new value is immediately available to authorized consumers. Any application that pulls the secret on each call (or caches it with a short TTL) will see the new value within seconds.

What about apps with long-running connections?

The grace period in Step 4 is for this. AWS SDK clients, EKS kubelet auth, and most long-lived consumers hold their credential for a while. Setting a grace period keeps the old key valid for that window so consumers can pick up the new one on their next refresh without erroring out.

For apps that don't poll regularly, subscribe to CoreLink's webhook event secret.rotated. Your consumer receives a POST on every rotation and can force-reload its cached credential. Covered in the rotation use case.

Next steps