Skip to content

Support 1Password for Secrets Manager

Release notes

GitLab CI supports read access to a 1Password Vault, and enables you to use Vault secrets in a CI job. The foundation for this has been done by offering read access to secrets stored in a HashiCorp Vault (see https://docs.gitlab.com/ee/ci/secrets/index.html#use-vault-secrets-in-a-ci-job)

The goal is to simplify the situation that a user has to manage a secret in his/her private personal password manager and has to ensure the correct version is being used in Gitlab CI for automation purpose. This integration would streamline and simplify the process as the user just has to update the password in the respective 1Password Vault without having to worry about the places its being used in Gitlab CI.

In the past it wasn't possible to have such an integration as 1Password didn't offer an API, which they now offer through Secrets Automation (https://1password.com/de/secrets/).

Problem to solve

Secrets stored in a 1Password Vault are currently not easily read by GitLab for CI Jobs. We want to support a user that has secret stored in 1Password and have it used by GitLab. Similar to what is being offered for HashiCorp Vault and has been developed in #28321 (closed).

Currently passwords being used for Gitlab CI/CD have to be stored in Gitlab itself so they are usable (obviously ...). These passwords have to be managed and stored elsewhere in (personal) password management tools. Therefor we're facing the situation that password management happens in at least 2 places. It is even more likely that there are a lot more places (personal password managers).

To make the whole process of managing passwords throughout a team or even across teams an integration with the popular password manager 1Password would increase the level of automation for secrets management in the devops lifecyle and decrease the risk of humans errors in the same field. All this while increasing the level of comfort for the developer / person who's in charge of actually managing the secrets.

Proposal

From a developer's point of view the integration of 1Password Secrets should be very similar to the way HashiCorp Vault secrets have been integrated.

For reference: https://docs.gitlab.com/ee/ci/secrets/index.html#use-vault-secrets-in-a-ci-job

Basically the yaml could be the same:

secrets:
  DATABASE_PASSWORD:
    one_password: <secret uuid>
    file: false|true

1Password would "just" be another backend for fetching secrets.

Authentication against 1Password can happen through their new Secrets Automation feature (https://1password.com/de/secrets/) by using 1Password vault access tokens. The integration itself can then be implemented using the 1Password Connect REST API (https://support.1password.com/connect-api-reference/).

Intended users

Development Team Lead, Software Developer, DevOps Engineer, Systems Administrator, Security Operations Engineer, Application Ops, Platform Engineer, Software Engineer in Test, Release Manager

User experience goal

The user should be able to simplify password / credentials management by integrating 1Password into Gitlab CI variables.

Further details

Permissions and Security

What permissions are required to perform the described actions? Are they consistent with the existing permissions as documented for users, groups, and projects as appropriate? Is the proposed behavior consistent between the UI, API, and other access methods (e.g. email replies)? Consider adding checkboxes and expectations of users with certain levels of membership https://docs.gitlab.com/ee/user/permissions.html

  • Add expected impact to members with no access (0)
  • Add expected impact to Guest (10) members
  • Add expected impact to Reporter (20) members
  • Add expected impact to Developer (30) members
  • Add expected impact to Maintainer (40) members
  • Add expected impact to Owner (50) members