Setting credentials for built-in Administrator accounts, break glass accounts, local administrator accounts and service accounts

// Latticework implementation guidance · partial coverage

Inspect credential issuance, lifetime and sharing

Practical suggestions for a Kubernetes or cloud system. Adapt these steps to your architecture and approved system boundary.

Implementation steps

1. Inventory workload and service identities, including credentials held outside Kubernetes. Prefer short-lived projected or dynamically issued credentials and explicitly set the intended audience.
2. Review legacy service-account token Secrets, default ServiceAccount use and credential sharing across workloads/environments. Test admission policies before rollout; assess existing credentials separately.

Evidence to retain

• Keep an identity-to-workload/environment inventory, credential issuer configuration, token lifetime/audience evidence and revocation/rotation records without recording secret values.
• Keep policy configuration and admission results, plus a separate existing-credential review. Demonstrate uniqueness and dynamic issuance directly; non-default account names do not establish either.

Responsibility boundary

Platform team: token issuer and admission configuration. Workload team: identity allocation and application secrets. Organisation: credential policy, break-glass custody and access reviews.

The public mapping’s detector allocation is provisional for both managed and self-managed clusters. Agree the responsibility matrix for the engagement; provider inheritance and whole-control ownership require a reviewed system boundary and applicable customer/provider evidence.

Mapped checks to inspect

• kyverno: ism-privileged-access-block-legacy-sa-tokens

These identifiers are from the pinned public mapping. Kyverno mappings describe the policy configuration you must inspect; they do not mean a policy is installed or enforcing. A manifest scan cannot establish live runtime behaviour. Record the exact tool, policy and framework versions, settings, exclusions and execution time with each result.

Review the mapping and control-specific limitations at revision 07b348a. Supporting mapping excerpts (checks, evidence notes and responsibility allocations) are adapted from Latticework Systems’ public repository under Apache-2.0. ASD’s control wording stays under CC BY 4.0.

Official source

ASD’s ISM OSCAL v2026.09.4 · Original catalogue JSON · Pinned checksums and edition details

Control source identifier: ism-1685. Check the official release before relying on this snapshot for an assessment.