Before you follow the steps in this guide, migrate your secrets from SecretHub to 1Password. You’ll need to keep the
1password-migration-plan.yml file you created in those steps to migrate your Kubernetes spec files.
With SecretHub, all integrations connect directly to the SecretHub API. Every time a secret is used, the encrypted data is fetched from the SecretHub servers. In contrast, with 1Password Secrets Automation, you can securely access secrets in your company’s apps and cloud infrastructure using a private REST API provided by a self-hosted 1Password Connect server, which uses 1Password.com as a backend. This means secrets are served to your applications with very low latency and in the rare event that the 1Password.com API is down, your secrets are still served from the Connect server.
Your applications fetch secrets from Connect using any of the integrations or by using the Connect API directly.
With Kubernetes, you have three options to load your secrets in applications:
- Use a Kubernetes Operator to create Kubernetes Secrets.
- Use an SDK.
- Use the Connect API directly.
1. Deploy a 1Password Connect server and set up a Kubernetes operator
Follow the steps to deploy a 1Password Connect server on Kubernetes and set up a Kubernetes operator. And yes, it includes a Helm chart! 🎉
2. Create OnePasswordItem resources
A Kubernetes operator can create secrets for 1Password items when you create
OnePasswordItem resources. For example:
apiVersion: onepassword.com/v1 kind: OnePasswordItem metadata: name: <item name> spec: itemPath: "vaults/<vault name>/items/<item name>"
1password-migration-plan.yml file you created when you migrated your secrets to generate these YAML files with the following command:
secrethub migrate config k8s --plan-file <plan-file> [--vault <vault-name>]...
Then apply the generated YAML file to create the Kubernetes secrets:
kubectl apply -f secrets.yaml
Your secrets are now provisioned to Kubernetes secrets from 1Password! 🎉 Secrets are automatically updated when you change items in 1Password. You can configure your Kubernetes operator to automatically initiate rolling restarts of your deployments any time a secret is updated, so that they always use the latest version of the secret.