A CI build role must push an image to Amazon ECR without access keys in the Jenkinsfile. How should programmatic access be configured?
Select an answer to reveal the explanation.
Short Explanation
CI shouldn’t carry permanent keys in the pipeline file. Let Jenkins (or GitHub Actions) federate with OIDC, assume a push role, and use short-lived credentials to talk to ECR.
Full Explanation
A CI build role should push images to Amazon ECR using short-lived credentials obtained by assuming an IAM role—commonly via OIDC federation from Jenkins, GitHub Actions, or similar—without embedding access keys in the Jenkinsfile. Temporary credentials limit blast radius if build logs leak and remove long-term secrets from source control, which is the modern baseline for municipal CI pushing container images.
Committing AKIA-style access keys into the repository’s Jenkinsfile is a classic secret leak waiting for a clone or log scrape. Making the ECR repository public so pushes need no authentication weakens supply-chain control and is unrelated to authenticated CI pushes into a private city registry. Storing root account credentials in a shared Slack channel for builders is an extreme privilege and secret-handling anti-pattern.
Exam caveat: the assumed role needs ecr:GetAuthorizationToken plus repository-level push/pull actions on the intended repo ARNs—least privilege, not AdministratorAccess on the account. Operational check: run the pipeline with OIDC or instance/role assumption, confirm the image push succeeds, and grep the Jenkinsfile, credentials store, and build logs to ensure no static AWS access keys remain for ECR.