Long-Lived Cloud Keys in a 42-Repository Pipeline

First priority is the exposed and over-privileged static cloud keys. A key in a public fork is a confirmed compromise path; an admin key increases blast radius from one service to the whole account. Immediate actions are revoke and rotate all 14 keys, reduce the two admin keys to scoped roles, and add detection for key use from unexpected networks. This is higher than OIDC because it removes a known live exposure, not a future design improvement.

Second is contractor identity. No MFA on personal accounts plus email-based rotation is a direct account-takeover path, especially for staff with production access. The likelihood is elevated by phishing and the 90-day rotation window; the impact depends on role, so start with contractors who can deploy or read customer data. Enforce SSO with MFA, time-bound accounts, and manager attestation.

Third is ownership metadata. Six hours to identify pipeline usage is an incident-response multiplier, not a primary compromise vector. Fix it through a repository-to-service catalog and automated tagging, but do not let catalog perfection delay key revocation. OIDC is the strategic fix; treat legacy exceptions as a controlled, time-bound risk rather than a reason to keep the current model.

For humans, centralize on the corporate IdP with SSO and phishing-resistant MFA. Contractors get separate agency-managed identities, not shared accounts, with time-bound group membership, least-privilege roles, and automated deprovisioning from the HR or agency roster. Production access is just-in-time with approval, session logging, and a maximum session length. Break-glass human access goes through a vault with dual approval and alerting.

For workloads, use OIDC federation from the CI/CD system to short-lived cloud roles scoped by service, environment, and action. Each pipeline gets its own role and trust policy restricted to the repository and branch. No static keys in repository variables. Kubernetes workloads use workload identity or service-account-to-role mapping, not node-level credentials.

For the nine legacy Jenkins jobs, do not exempt them indefinitely. Put them behind a migration queue: either run them on an OIDC-capable agent, or issue dynamic credentials from a secrets manager with a 1-hour TTL and a network restriction. For the vendor appliance, use a static key only in a vault, bound to a fixed egress IP, rotated every 30 days, scoped to the minimum API, and monitored for anomalous calls. Document the exception owner and expiry. The target is zero long-lived keys in repositories, with a small number of vaulted, monitored exceptions.

Evidence should be machine-generated, timestamped, and tied to a control. Maintain an inventory of cloud access keys showing age, owner, privilege, and last use; the target metric is zero keys in CI variables and zero admin keys used by pipelines. Report OIDC adoption by repository, MFA coverage by human and contractor cohort, and contractor accounts with last-login and manager attestation. Keep a register of approved exceptions with scope, compensating controls, and expiry.

Guardrails in the pipeline should fail a build when a static cloud key pattern appears in a repository or when a workflow requests a role outside its allowlist. Cloud policy should deny creation of long-lived access keys for service accounts except through a break-glass workflow, and alert on any new admin policy attachment. Add anomaly detection for key use from new IP ranges, high-volume bucket enumeration, and calls outside the service's normal API set.

Prevent regression with ownership metadata in the repository catalog, automated rotation tests, and a monthly access review that samples contractor and break-glass activity. After the incident, run a tabletop to test whether the team can identify key usage in under 30 minutes. Report the key inventory and exception register to audit quarterly. The point is not a one-time cleanup; it is a control that shows drift quickly.