2023-21: My 1Password Key Management Practice

/ Xuanwo | 漩涡 | Base Tianjin

Original link: https://xuanwo.io/reports/2023-21/

This weekly report shares my 1Password key management practice, the main content includes common password management, SSH/Shell integration and CI/CD application.

These practices should also apply to services like bitwarden .

password management

Common SaaS service password management can be created directly using the 1Password cross-platform client. Personally, I will follow the following principles:

Every website uses a randomly generated unique password

1Password uses Smart Password by default to generate according to the requirements of the website. If you are not satisfied, you can fine-tune it yourself, such as generating a 32-bit password with uppercase and lowercase letters, numbers and symbols.

2-step verification should be turned on

Two-step verification is a very effective means of protecting account security. If the website itself supports it, it should be enabled as much as possible.

I personally prefer TOTP (Time-based one-time password) over SMS-based two-step verification schemes:

  • TOTP is a pure offline calculation, no need to wait to receive text messages, faster
  • TOTP can be better integrated with the login process. For example, 1Password will automatically copy the code after successful login, and some supported websites will also be directly filled automatically, making the experience smoother
  • TOTP is phone independent and works even when your phone is away or lost

1Password’s browser plug-in integrates the Scan QR Code function, which can be scanned directly when two-step verification is turned on.

Security question and answer is also password

There are not many services that still need to set secret questions and answers, but if you need to set them, please consider them as part of the password: don’t use real answers, record the original text of the question, and use a password generator to generate random string as the answer.

SSH integration

1Password has aggressively developed a series of developer tools since its last funding round, and SSH integration is one of them.

For me it solves the following problems:

  • There is no need to store the SSH Secret Key locally, which avoids key leakage and the possibility of being read by malware
  • When the machine fails or needs to be migrated, there is no need to consider key synchronization to avoid key loss
  • All access to SSH Key requires an explicit pop-up request from 1Password to avoid silent access by malware in the background

Its idea is very simple: develop an SSH Agent and expose it as SSH_AUTH_SOCK , so that all SSH Key requests are processed by the local 1Password client.

After the configuration is complete, the following window will pop up when all applications access the specified SSH Key for the first time:

This window will show that application X tries to access SSH Key Y, and the content of the key can only be obtained normally after the authentication is passed. Depending on the configuration of each system, it supports biometric authentication such as Apple Touch ID and Windows Hello. It also provides complete polkit and PAM support on the Linux platform, and will call the system’s built-in user authentication mechanism to provide a native experience.

Configure SSH Agent

To use this feature, you first need to configure 1Password SSH Agent correctly.

Check and enable SSH Agent in the configuration of the 1Password client:

Add the following configuration to ssh config to specify IdentityAgent :

 Host * IdentityAgent ~/.1password/agent.sock

According to the actual situation, you can add some additional configurations to different Hosts, such as specifying that the Host does not use 1Password:

 Host ec2-server HostName 1.2.3.4 User ec2-user IdentityFile ~/.ssh/ssh-key-not-on-1password.pem IdentityAgent none

Or specify a key for it:

 Host github.com User git IdentitiesOnly yes IdentityFile ~/.ssh/github.pub

Finally, set SSH_AUTH_SOCK :

 export SSH_AUTH_SOCK = ~/.1password/agent.sock

Migrating SSH Keys

After completing the SSH configuration, we can start to migrate our own SSH Key. Currently 1Password supports Ed25519 and RSA (2048-bit, 3072-bit, and 4096-bit) keys, click New Item , select SSH Key , and then add Private Key to it. After the Private Key is added, 1Password will automatically generate a series of information for distinction (full score for the experience!):

After the configuration is complete, you can use commands such as git fetch to verify~

Shell integration

In addition to SSH integration, 1Password has developed shell-plugins based on their CLI. The problem it solves is similar to that of SSH integration: many developers store the keys of services such as AWS/GCP/Github in a static manner on their local computers, and if they are leaked, the test environment or even the production environment may be affected. The idea is also very simple, 1Password is responsible for storing the actual key, and 1Password Plugin is a simple layer of wrapper, which replaces environment variables such as GITHUB_TOKEN with the actual key, and then calls the corresponding command.

Taking Github Plugin as an example, the local op/plugins.sh content is as follows:

 export OP_PLUGIN_ALIASES_SOURCED = 1 alias gh = "op plugin run -- gh"

The corresponding specific implementation is:

 func GitHubCLI () schema.Executable { return schema.Executable{ Name: "GitHub CLI" , Runs: [] string { "gh" }, DocsURL: sdk. URL ( "https://cli.github.com" ), NeedsAuth: needsauth. IfAll ( needsauth. NotForHelpOrVersion (), needsauth. NotWithoutArgs (), ), Uses: []schema.CredentialUsage{ { Name: credname.PersonalAccessToken, }, }, } }

Configuring shell integration is also very simple:

 # Signin op to make sure op itself works op signin # Setup plugin gh op plugin init gh

All shell plugins are open source in shell-plugins and developed with Golang. If you have command line tools you want to support, please submit a PR!

CI/CD application

The last thing I want to share is the application of 1Password in CI/CD. Github Actions provides built-in Secrets function, but there are the following problems:

  • Secrets require Admin permissions, but sometimes project maintainers may only have Committer permissions (for example, adding and modifying Secrets in the ASF project requires submitting a work order to the Infra team)
  • Secrets can only be configured per repo or per org, and the configuration is complicated and troublesome when writing across multiple repos
  • Secrets can only be used on the Github platform and cannot support scenarios such as local development and debugging

The OpenDAL project encountered these problems:

  • A large number of services in OpenDAL need to be configured with Secrets, and some of them need to be rotated periodically. Modifying them through the ASF Infra team not only takes a long time, but also greatly increases the workload of the other party.
  • OpenDAL’s Committer also relies on Secrets when debugging services, but it is difficult to guarantee the security and synchronization of Secrets during delivery

To this end, the OpenDAL team adopted a key management scheme based on 1Password.

Apply for a 1Password Open Source Sponsorship

Thanks to 1Password for its strong support for open source projects, just submit a PR to 1password-teams-open-source to get a free 1Password Teams membership. See the PR submitted by OpenDAL: Add Apache OpenDAL (incubating) . OpenDAL creates an independent Services Vault and grants permissions to all PPMC and Committers, which ensures the consistency of access to all Secrets within the team and eliminates the single point of dependence on @Xuanwo.

Set up 1Password Services Account

In a recent update, 1Password added the Service Account function, which supports authorizing the account to access a specific vault. We submitted an application to Infra team to activate 1Password/load-secrets-action and set OP_SERVICE_ACCOUNT_TOKEN . So far, our Github environment has been able to obtain the key stored by 1Password from CI normally.

Configure Github Actions

Next, we only need to use load-secrets-action to load the secret. Take OpenDAL to configure the COS service as an example:

 - name : Load secret  
 id : op-load-secret  
 uses : 1password/load-secrets-action@v1  
 with :  
 export-env : true  
 env :  
 OP_SERVICE_ACCOUNT_TOKEN : $  
 OPENDAL_COS_TEST : op://services/cos/test  
 OPENDAL_COS_BUCKET : op://services/cos/bucket  
 OPENDAL_COS_ENDPOINT : op://services/cos/endpoint  
 OPENDAL_COS_SECRET_ID : op://services/cos/secret_id  
 OPENDAL_COS_SECRET_KEY : op://services/cos/secret_key  
  
- name : Test  
 shell : bash  
 working-directory : core  
 run : cargo test cos -- --show-output  
 env :  
 RUST_BACKTRACE : full  
 RUST_LOG : debug
  • export-env means to export these keys as environment variables
  • OP_SERVICE_ACCOUNT_TOKEN is the service account token we configured before
  • op://services/cos/test indicates that the value of test field in cos entry of services vault is used to replace

It should be noted that this scheme also relies on the static OP_SERVICE_ACCOUNT_TOKEN key, if leaked it may lead to key leaks in the entire vault, so:

  • If the scenario is not as complicated as OpenDAL, please use actions such as configure-aws-credentials and google-github-actions/auth to implement keyless authentication based on GitHub OIDC
  • All keys configured to enter the Vault must follow the principle of minimization, and can only access specified resources. For example, AWS resources need to be configured with IAM sub-accounts and limit permissions through roles

Summarize

This article shares my practical experience of using 1Password in my daily work and life, hoping to provide some reference for everyone to design their own key management solutions!

This article is transferred from: https://xuanwo.io/reports/2023-21/
This site is only for collection, and the copyright belongs to the original author.