# Secrets in CI/CD — 1Password and Secrets Hygiene for Developers

Source: https://www.geekswithgeeks.com/en/secrets-hygiene/dev-ci-secrets

> Use CI secret stores, service accounts and short-lived credentials instead of long-lived keys.

## A machine needs its own identity

CI should never use a person's credentials. Create a **service account** with access to only the vaults a pipeline needs and store its token in the CI system's secret store. Where your cloud supports it, prefer short-lived credentials (OpenID Connect) over stored long-lived keys.

## A GitHub Actions step

The service account token lives in GitHub Secrets. The step loads one secret into the job and masks it in logs.

```yaml
- name: Load secrets
  uses: 1password/load-secrets-action@v2
  with:
    export-env: true
  env:
    OP_SERVICE_ACCOUNT_TOKEN: ${{ secrets.OP_SERVICE_ACCOUNT_TOKEN }}
    DATABASE_URL: op://CI/Postgres/url
```

## Never print in CI

Do not `echo` secrets or run shell tracing (`set -x`) in jobs that handle them. Be careful with pull requests from forks: do not expose secrets to untrusted code.

**Quiz:** What should a CI pipeline authenticate with?

- [ ] A developer's personal login
- [x] A scoped service account
- [ ] The master password
- [ ] No authentication

*Answer:* A scoped service account. A service account can be limited and revoked without affecting any person.