I85PREP
⌘ K
JFrog Artifactory Certified DevOps Engineer study materials
JFrog Artifactory Certified DevOps Engineer study resources

Admin-scoped CI token leaked and the permission model is rebuilt

JFrog Artifactory Certified DevOps Engineer · Put your knowledge to work in context.

All case studies

Admin-scoped CI token leaked and the permission model is rebuilt

Fabrikam has 250 developers using Artifactory 7.84 with Active Directory via LDAP. CI runs in Jenkins and uses a shared local user svc-ci whose admin-scoped access token is stored as a Jenkins credential and passed to jf rt as --access-token. A contractor copied the token into a public GitHub repository; the token has no expiry. The security team sees unusual downloads of libs-release-local and a new repository test-delete-me created at 02:14. Anonymous access is disabled, but the token can create users and permission targets. The company wants CI to deploy only to libs-release-local and read npm-remote, while developers use their AD accounts and groups. They also need to keep build-info publishing working for 30 days and pass an audit that requires named accountability and least privilege. The platform team has one maintenance window.

1. What immediate containment steps would you take, and which logs and artifacts would you preserve?

Read the worked answer

Containment

  1. Revoke the exposed token by token ID and disable or reset svc-ci. Revoke any API keys and other tokens for that user; assume the contractor copied more than one secret.
  2. Remove the Jenkins credential, rotate it, and scan CI logs and job definitions for other uses of the token. Enable secret masking and pass tokens through environment variables or the credentials binding, not --access-token on the command line.
  3. Inspect and quarantine test-delete-me; check for new users, groups, permission targets, replication jobs, and deployed artifacts after 02:14.
  4. Preserve evidence: Access and audit logs, Artifactory request logs, Jenkins build logs, GitHub secret-scanning alerts, and the token metadata. Do not delete the malicious repository until it is captured.
  5. Review downloads from libs-release-local for data exfiltration and notify security.

Reasoning

The token was admin-scoped and non-expiring, so revocation is not enough; you must find persistence the attacker may have created. Preserving logs protects the audit trail.

2. Design the least-privilege replacement: groups, permission targets, token scope and expiry, and LDAP mapping.

Read the worked answer

Least-privilege design

  • Create AD group GRP-ART-CI-DEPLOY and map it to Artifactory group ci-deployers. Keep developers in separate AD-mapped groups; do not reuse the CI group for humans.
  • Permission target ci-deploy: repositories libs-release-local and artifactory-build-info; include patterns such as com/fabrikam/**; actions read, deploy, cache, and annotate only. No delete, manage, or admin.
  • Permission target ci-read-npm: repository npm-remote; actions read and cache only.
  • Service user svc-ci belongs only to ci-deployers and ci-read-npm; no admin group.
  • Issue a scoped, expiring token for svc-ci bound to those groups. Prefer a 30-day expiry with rotation, or OIDC workload identity if the platform supports it.

Reasoning

Build-info publishing needs write access to the build-info repository, not platform admin. Separating deploy and read targets limits blast radius if the token leaks again. LDAP mapping keeps named accountability for humans while the service account remains auditable.

3. How would you verify the new model and what audit evidence would you produce?

Read the worked answer

Verification matrix

  • Positive: svc-ci can deploy a test artifact under com/fabrikam/ to libs-release-local, publish build-info, and read and cache an npm package.
  • Negative: it cannot deploy outside the include pattern, delete an artifact, create a repository or user, or change a permission target.
  • Token: confirm subject, scope, expiry, and that it cannot be used after revocation.
  • LDAP: a developer in the mapped AD group gets the expected role; a developer outside it does not.

Audit evidence

Export the permission targets, group memberships, token metadata, and a redacted CI job log showing the token is not printed. Keep sample Access and audit log entries for the test deploy and the failed admin attempt. Record the rotation date and owner. A successful audit needs to show both technical enforcement and an accountable owner, not just a policy document.