Access keys, rotation, and credential handling

Why this matters in production

Unlike cephx, an RGW user can hold several key pairs at once. That single property makes rotation a routine operation rather than a coordinated outage, and it is worth knowing before a credential leak forces the question.

Key pairs

radosgw-admin user info --uid=analytics | jq '.keys'

[{"user": "analytics", "access_key": "8FQ...", "secret_key": "kR2..."}]

The access key identifies the credential; the secret key signs requests and is never transmitted.

Creating additional keys

radosgw-admin key create --uid=analytics --key-type=s3 \
    --gen-access-key --gen-secret

radosgw-admin user info --uid=analytics | jq '.keys | length'
# 2

Both key pairs are now valid. Either authenticates as the same user with the same permissions.

Rotation

# 1. create the new pair and capture it
radosgw-admin key create --uid=analytics --key-type=s3 --gen-access-key --gen-secret

# 2. distribute to consumers and switch them over

# 3. verify the old key is no longer in use
radosgw-admin usage show --uid=analytics --show-log-entries=true | \
  jq -r '.entries[].buckets[].categories[]' | head

# 4. remove the old key
radosgw-admin key rm --uid=analytics --access-key=OLDACCESSKEY

The overlap in step 2 is what makes this safe: consumers migrate individually, and one that is missed keeps working until step 4.

Specifying a key explicitly

radosgw-admin key create --uid=analytics --key-type=s3 \
    --access-key=AKIAEXAMPLEKEY --secret-key=examplesecretvalue

Useful for migrations where an application’s credentials cannot be changed easily. The trade is that you have chosen the key material rather than letting it be generated.

Swift credentials

radosgw-admin subuser create --uid=analytics --subuser=analytics:swift --access=full
radosgw-admin key create --subuser=analytics:swift --key-type=swift --gen-secret

Swift credentials attach to a subuser rather than to the user directly.

Handling

• Capture generated keys at creation — they are shown once
• Store in a secret manager, never in configuration files in version control
• Treat any key that has appeared in chat, a ticket, or a log as compromised
• Rotate on staff departure and on any suspected exposure
• Prefer per-application keys so revocation is surgical

Quiz

Production discipline

Issue per-application access keys so a compromise can be revoked surgically, and rotate on a schedule rather than only after incidents — the overlap property makes routine rotation cheap. Capture generated keys at creation into a secret manager; they are displayed once and regenerating means another rotation.

Cross-course references

• Kubernetes: multiple valid ServiceAccount tokens during rotation follow the same pattern
• Linux: SSH authorized_keys with both old and new keys present is the identical strategy