ONTAP S3 access-key rotation

An S3 credential is an access-key and secret-key pair. This runbook separates issuing the replacement, moving every client, proving the cutover, and retiring the old credential.

Choose the workflow by release

Capability	Pattern	Risk
One key per S3 user	Maintenance window; regenerate, update all clients, test	Old credentials stop working at regeneration
ONTAP 9.19.1 dual keys	Create key 2, move clients, prove key 1 unused, remove key 1	Non-disruptive if every consumer is found
ONTAP 9.14.1+	Optionally assign a TTL when generating a key	Clients fail after expiry unless rotated first

Never paste real secrets into tickets, chat, or shell history. ONTAP shows a new secret only at creation or regeneration. Store it in the approved secret manager during the change.

1. Inventory and prepare

Identify the exact SVM, user, applications, gateways, backup jobs, scripts, and secret-store references. Confirm the release before using dual-key flags.

cluster::> version
cluster::> vserver object-store-server show -vserver svm_s3
cluster::> vserver object-store-server user show -vserver svm_s3 -user backup_app
cluster::> vserver object-store-server user show -vserver svm_s3 -user backup_app -instance

The user listing shows access-key identifiers and, on supporting releases, TTL and expiry. It never reveals the secret. Capture identifiers and expiry—not secrets—in the change record.

Establish a known-good data-plane test first. Use the application's health check or a least-privilege operation against an agreed test object. DNS and TLS success do not prove S3 authentication or authorization.

2A. Single-key rotation

Use this path where only one usable key exists. Regeneration replaces that credential, so prepare every client update and treat this command as the cutover:

cluster::> vserver object-store-server user regenerate-keys \
  -vserver svm_s3 -user backup_app

Capture the returned pair directly in the approved secret store.
Update clients through their normal secret mechanism.
Run the agreed read/write/list tests permitted by policy.
Check every scheduled and standby consumer, not only an interactive canary.

A lost secret cannot be recovered with user show. Regenerate again and distribute the new pair.

2B. Dual-key rolling rotation in ONTAP 9.19.1

The following creates key 2 with a seven-day TTL. Choose a TTL that covers rollout and rollback in your environment.

cluster::> vserver object-store-server user regenerate-keys \
  -vserver svm_s3 -user backup_app -key-id 2 -key-time-to-live P7D

cluster::> vserver object-store-server user show \
  -vserver svm_s3 -user backup_app -instance

Save key 2's secret when displayed.
Move a canary, prove its allowed operations, then roll out.
Observe a full job cycle. A key listing cannot prove which key clients use.
After the rollback window and independent evidence that key 1 is unused, remove it.

cluster::> vserver object-store-server user delete-keys \
  -vserver svm_s3 -user backup_app -key-id 1
cluster::> vserver object-store-server user show \
  -vserver svm_s3 -user backup_app

Always specify -key-id. NetApp documents that delete-keys defaults to key 2 when omitted. An explicit ID makes the destructive target reviewable.

3. Expiration and TTL

Beginning with ONTAP 9.14.1, generated keys can receive a TTL. Accepted documented forms include:

# One day, two hours, three minutes, four seconds
-key-time-to-live P1DT2H3M4S
# Two weeks
-key-time-to-live P2W
# No automatic expiry
-key-time-to-live 0

A TTL is not automation. Alert before expiry and account for paused jobs and DR consumers. Dual-key behavior is release-specific; do not copy the 9.19.1 sequence onto an older cluster.

4. Verification and recovery

Control plane: user show -instance lists the intended ID and expiry.
Data plane: clients perform only their required bucket/object operations.
Coverage: scheduled, standby, restore, proxy, and DR consumers have run.
Security: the secret is in the approved store and temporary copies are removed.
Retirement: the old key is deleted only after evidence.

For authentication failures, confirm endpoint, time, access-key ID, signature, and policy using the S3 troubleshooting guide. Repeated regeneration destroys evidence and invalidates credentials still under diagnosis.

Rollback boundary: before old-key deletion, restore the previous client credential. After deletion, the old secret cannot be re-enabled; issue and distribute a new key.

Primary sources and currency

Reviewed 10 September 2026 against ONTAP 9 documentation and the 9.19.1 CLI reference. Validate syntax on the target release with command help before production use.