HARBOR CLOUD / 06 / PRACTICE GUIDE

Cloud secrets, KMS and rotation

Separate encoding, encryption, access and rotation. Complete new-secret creation with safe consumer migration and revocation of old authority.

Download guide and workpapers

Original AI-assisted SecNet educational content; examples are fictional. Not a source organization publication or endorsement. Sources checked: 2026-10-21.

CODE REVIEW DESK

See the decision through the test.

Code here is a local policy model with no target connection. Passing model cases are not security approval or device tests.

Does base64 protect it? / Weak code

Inspect an incomplete decision based on record existence or another positive signal. Consider denial cases alongside permitted use.

s=>s.base64

Encoding is neither storage encryption nor scoped access. A log copy still requires rejection under this profile even when other controls exist; no real secret is modeled.

Choices and outputs last only on this open page; they do not update account progress, career status, points or certificates.

01 / EXPLANATION

Encoding is not encryption

Base64 values in Kubernetes Secrets are easily decoded, not confidentiality evidence. Storage encryption, API authorization and in-app use are separate layers. Do not copy values into logs, crash reports or CI output. Review who can decrypt through KMS; ciphertext plus broadly granted decrypt authority is not a meaningful boundary. No real Secret is uploaded here; models use fictional evidence fields only.

02 / EXPLANATION

Treat rotation end to end

Creating a new version is only the first step. Test consumer refresh, restart requirements, old-credential revocation and failure behavior during transition together. Check that old values are not logged. A compatible transition window may be necessary before revocation; assign an owner and expiry. If the old credential still authorizes actions, the security purpose of rotation is incomplete.

03 / EXPLANATION

Keys and backup dependencies

Encrypted backups cannot be recovered without keys. Include key access, a separate recovery identity and secret-provider dependencies in recovery planning. Verify provider-specific key recovery rules; do not assume every KMS key is exportable. Assess whether recovery authority shares the application administrator’s compromise domain. Preserve controlled restoration observations rather than plan text alone.

04 / EXPLANATION

Worked example: a new version, old token

The Harbor API receives a new token, but the prior token remains valid in another running Pod. newVersionCreated=true does not establish completed rotation. The model separately checks consumerRefreshed and oldCredentialRevoked. Record synthetic-identity outcomes instead of token values in actual evidence. Falling back to plaintext storage or disabling validation after refresh failure is not an acceptable failure policy. Link revocation and impact investigation to the rotation record when responding to an incident.

Build the evidence yourself.

Blank workpapers are not completed tests. Fill them in your authorized environment without secrets or real personal data.

Scope and trust boundariesMarkdown · EN Test plan and expected resultsMarkdown · EN Finding and retest recordMarkdown · EN Release decision and evidence traceMarkdown · EN

Full guide with code, outputs and reasoning ↓

Primary references

Explanations are authored by SecNet. References support method and platform context; verify current editions and organizational policy for real use.