Security Hardening

This page is about what you set up on your side: the access each token and user holds, where a token lives, and what to do when one leaks. How CloudRepo protects the service itself is on CloudRepo’s security page, which is where those practices are published.

Give each pipeline its own token

A repository token is the credential your build tools send. Create one for each pipeline or tool, and name it for where it is used, so the token list says what each is for:

• Choose Read only for a job that only pulls. A Read only token downloads and cannot publish. Choose Read + write for a job that publishes.
• Tick only the repositories the job uses. A token reaches only the repositories you tick when you create it.
• Give it an expiry, and replace it before that date. Choose 90, 180 or 365 days, pick a date, or choose never. A token that never expires has no date to replace it by, so keep that choice for the few places that need it, and revoke the token when the need ends.
• Rotate with an overlap. Rotating a token gives you a new value and keeps the same expiry, and the Rotate dialog lets the old token keep working for up to 7 days, so a running job can switch first. It does not extend the token’s life: to extend it, create a new token with a new expiry, put it in your secret store, then revoke the old one.

Give people the access they need

Make anyone who only downloads a Read Only User, and give a user an administrator permission only for the area they manage: billing, repositories, software distribution, users or webhooks. User Management shows both settings.

To let the customers you distribute software to download it, give them access through Software Distribution instead of making them users: a subscriber’s access key is read only.

Keep tokens out of code, logs and images

• Keep the token in your CI system’s secret store, hand it to the one step that needs it as an environment variable, and name the variable, never the token, in a committed file. CI/CD overview shows the file each client reads.
• Put the token on no command line. A tool’s own configuration file or an environment variable carries it, as each client page shows.
• In a Docker build, pass the token as a build secret, never as a build argument. See Install packages from CloudRepo in a Docker build.
• Check a debug log before you share it. A client’s verbose output can hold a token. See Read your client’s debug output safely.

If a credential leaks

1. Revoke the token. Open Repository Tokens in the admin portal, find the token and revoke it. Then create a replacement with its own expiry and put it in your secret store.
2. If a user’s password leaked, change it. In Users, open the user and click Change Password (User Management).
3. If the person has left, delete the user. Deleting a user deletes that user’s tokens, so a pipeline that used one stops authenticating. Build pipelines belong on an account that outlives any one person (CI/CD overview).
4. Tell us at support@cloudrepo.io, and report a security concern through the contact details on CloudRepo’s security page.

Scanning the packages you store

Whether CloudRepo scans the packages you store is answered in Does CloudRepo scan packages for vulnerabilities?