Cross-Account Access and Key Management for a Contractor Team
A company runs production in one cloud account and a shared services account for logging and CI/CD. Twelve contract developers need read access to production logs and permission to deploy to a staging environment in the production account. Contracts end on varying dates, and the security team wants no long-lived credentials stored on contractor laptops. The CI/CD system already runs in the shared services account with a service identity. An auditor flags that the current setup uses a shared access key committed to a CI configuration file, and that production logs are readable by anyone with the key.
1. Design the identity and access approach for the contractors and the CI/CD system, addressing the auditor's findings and the varying contract end dates.
Read the worked answer
Principle: eliminate long-lived credentials and centralize identity.
Contractors:
- Create a federated identity path so contractors authenticate through the company identity provider and assume a role - no static keys on laptops. Each contractor maps to an individual identity, so actions are attributable.
- Define two roles: a read-only logs role scoped to production log resources, and a deploy role scoped to the staging environment only. Do not bundle them; a contractor who only needs logs should not hold deploy rights.
- Time-bound access: tie role sessions to short maximum durations and drive membership from the identity provider's groups, so removing a contractor from the group on their end date revokes access automatically. Add a periodic access review to catch drift.
- Scope the logs role with resource-level conditions (specific log groups) rather than account-wide read.
CI/CD:
- Replace the committed access key with a workload identity / role assumption from the CI system's service identity in the shared services account. The CI role trusts only that identity, and the trust policy is the control - no secret to leak.
- Rotate and revoke the exposed key immediately and purge it from version history; assume it is compromised.
- Scope the CI deploy role to staging, with production deploys requiring a separate, approval-gated role.
This directly answers the auditor: no shared key, least privilege on logs, and access that expires with the contract.
2. The security team asks whether to store the CI/CD secrets in a managed secrets service or in encrypted environment variables in the pipeline. Recommend one and explain the residual risks either way.
Read the worked answer
Recommend a managed secrets service, but be precise about why.
Encrypted environment variables in the pipeline are better than a committed key, but they still expose the secret to every process in the build environment, appear in crash dumps and debug logs, and are typically readable by anyone who can edit the pipeline definition. Rotation is manual and rarely done.
A managed secrets service gives: centralized rotation, fine-grained access policies tied to the CI role, audit logging of every retrieval, and the ability to fetch the secret at runtime only when needed rather than injecting it into the whole environment.
Residual risks either way:
- The CI role itself becomes the crown jewel. If an attacker can modify the pipeline or assume the CI role, they can fetch the secret. Mitigate with protected branches, required approvals on pipeline changes, and a trust policy that limits which workflows can assume the role.
- Secrets in memory and logs. Runtime fetching reduces but does not eliminate exposure; mask secrets in logs and avoid printing them in error paths.
- Rotation gaps. A secrets service makes rotation easy but does not force it; set a rotation schedule and alert on age.
- Over-broad secret scope. One secret used by many services means one leak compromises all; split secrets per service.
The judgement: the choice of store matters less than the trust boundary around whoever can read it.