Treat the mirror admin role like a production deploy key. Give it to two or three named people, sign in through your identity system with multi-factor authentication, keep the built-in admin account as a sealed break-glass login, and review admin actions on a schedule. Day to day work should never need admin.
Why the admin role is powerful
An admin can edit repository settings, change which repository answers first, add users and tokens, and upload or delete artifacts. Reordering a group or loosening a proxy rule can change what every build installs, with no commit in your source repositories to show for it. So admin access is a supply chain control, not a convenience.
Three kinds of account
| Account | Purpose | Rule |
|---|---|---|
| Named admin | Occasional configuration work | One per person, multi-factor, used only when needed |
| Service account | CI reads and publishes | Scoped, no admin, secret in a vault |
| Break-glass | Recovery if sign-in is down | Sealed, long random password, alarm on use |
Steps to lock it down
- List current admins. Many mirrors start with a default account and a shared password. Find out who knows it.
- Change defaults. Replace any default admin password at install time, and disable anonymous access unless it is a deliberate choice.
- Move people to single sign-on if the software supports it, so offboarding and multi-factor apply automatically.
- Reduce admins to the smallest group that can cover vacations.
- Create a break-glass account. Generate a long password, store it in a vault with two person access or a sealed envelope, and set an alert on any login.
- Separate duties. The person who approves a new public dependency should not be the only one who can change the mirror configuration without review.
- Log admin actions and review them monthly. Look for permission changes, new tokens and repository edits.
Protect the host too
Even a well configured admin account fails if the host is weak. Keep the operating system and the mirror software patched, expose the admin interface only to a management network or VPN, and put TLS on every connection. Repository managers are server software and receive security advisories like any other, so subscribe to your vendor's or project's announcements and patch promptly.
Review regularly
Every quarter, answer four questions. Who has admin? Does each still need it? When was the break-glass credential last rotated or tested? Were any admin actions made that nobody can explain? Write the answers down. If the answer to the last one is yes, treat it as an incident and check what changed.
Where Safeguard fits
Safeguard's agent identity and policy features support the same principle for machine and agent access: named identities, limited scope, reviewable actions. A free scan is at gold.safeguard.sh/scan.
Quick check
Can CI use an admin token for convenience?
Avoid it. If the token leaks, an attacker controls the mirror. Use scoped service accounts.
How often should we test break-glass access?
At least twice a year, then rotate it. A credential nobody has tested may not work when needed.
Last reviewed: 19 October 2026.
