Skip to main content

Kubernetes Injector

The 1Password Kubernetes Secrets Injector implements a mutating webhook that allows you to inject 1Password secrets using a service account or a Connect server to authenticate to 1Password.

Unlike the 1Password Kubernetes Operator, the Secrets Injector doesn't create a Kubernetes Secret when assigning secrets to your resource. See Kubernetes integrations to compare the Kubernetes Operator and the Kubernetes Injector.

tip

Learn how to use the Kubernetes Secrets Injector with a 1Password Service Account.

Requirements​

Before using the Kubernetes Injector, make sure you:

Limitations​

There are some limitations and nuances to consider about the Kubernetes Injector. For example:

  • The Kubernetes Injector requires deployment specifications to use the command field.
  • Secrets aren't available to all a container's sessions by default.

The command field​

The Kubernetes Secrets Injector works by changing the command value on initialization. As a result, the pod you want to inject secrets into must have a command value defined in its deployment specification file (as shown in the following code block).

See the command field in the code block below. In this example, a 1Password Service Account injects secrets into the application run by npm start.

deployment-specification.yaml

If the deployments you're using aren't designed to have a command field specified in the deployment, then the 1Password Kubernetes Operator might be a better fit for your use case.

Session availability​

Injected secrets are available only in the current pod's session. You can only access the secrets for the command listed in the container specification. To access it in any other session, for example, using kubectl, it's necessary to prepend op run -- to the command.

In the service account example deployment specification, the app-example1 container will have injected the DB_USERNAME and DB_PASSWORD values in the session executed by the command npm start.

Another way to have secrets available in all sessions for a container is by using the Kubernetes Operator.

Deployment​

Use the following instructions to configure and deploy the Kubernetes Injector with your service account or Connect server and Kubernetes deployment.

Notes about strings and variables used in these code examples.

Some strings used throughout the code examples on this page are variable and arbitrary. Other strings have specific meanings within the context of 1Password.

The following strings used in the code examples on this page have very specific and hard-coded meanings within the context of 1Password:

  • OP_CONNECT_HOST
  • OP_CONNECT_TOKEN
  • OP_SERVICE_ACCOUNT_TOKEN

The following strings used in the code examples on this page have are variables and don't have specific meanings within the context of 1Password:

  • DB_PASSWORD
  • DB_USERNAME

Step 1: Enable secrets injection​

Use kubectl to enable secrets injection by adding the secrets-injection=enabled label to your namespace (NAMESPACE) . The Kubernetes Injector uses the default namespace unless you specify a custom namespace.

Step 2: Deploy the injector​

Use the kubectl apply command to the deployment specification files. When you use manual deployment, you must apply each deployment specification file separately.

In the following example, INJECTOR.yaml is the name of the Kubernetes Injector deployment specification file and CONNECT.yaml is the name of the Connect deployment specification file.

To undeploy, use kubectl delete.

The commands in this example only deploy the Kubernetes Injector and Connect. They don't handle additional configuration you might need, like permissions , namespaces , and custom resource definitions (CRD) .

tip

You can deploy and configure the Kubernetes Injector in one command if you use the 1Password Secrets Injector Helm chart.

info

The Kubernetes Injector creates the necessary TLS certificate for the webhook when it's deployed (deployment.yaml ). If you remove the Kubernetes Injector from the cluster, it automatically deletes the TLS certificate.

Step 3: Annotate your deployment specification​

Annotate your Kubernetes deployment specification with operator.1password.io/inject: followed by a comma-separated list of the containers you want to mutate and inject secrets into.

  1. Edit your deployment specification file and add the following annotation:

    deployment-specification.yaml

Step 4: Configure the resource environment​

Add an environment variable to your pod or Kubernetes deployment specification with a value referencing your 1Password item using a secret reference.

  1. Edit your deployment specification file and add an environment variable containing the path to the 1Password item. Make sure to replace VAULT , ITEM, SECTION, and FIELD with the correct values.

    deployment-specification.yaml

    The value should look something like the text in the following code block:

    deployment-specification.yaml

Step 5: Add your 1Password credentials to your deployment​

Step 5.1: Create a Kubernetes Secret with your authentication token​

To authenticate to 1Password, you'll need to create a Kubernetes Secret that contains your service account or Connect server token.

You can pass your service account token to Kubernetes using the kubectl create secret command:

note

Your service account token is generated automatically during the service account creation process. If you lose the token, you must create a new service account.

This creates a generic Secret named op-service-account with a key named token that contains your service account token.

Step 5.2: Add the Secret to your Kubernetes deployment specification file​

You can reference the Secret you created for your service account or Connect server token in your Kubernetes deployment specification file using an environment variable. Kubernetes will automatically inject the authentication token into your pod or deployment when it starts.

Add an environment variable named OP_SERVICE_ACCOUNT_TOKEN to your deployment specification file, and set the valueFrom to reference the Kubernetes Secret you created in the previous step.

If you used a custom Secret or key name, make sure to update the example to use the appropriate name and key.

deployment-specification.yaml

caution

If you configure the Kubernetes Injector to authenticate with both a service account and a Connect server, the Connect server will take precedence.

Usage examples​

The following Kubernetes deployment specification files show what your deployment file should look like.

The following code block contains an example of a Kubernetes deployment specification YAML file setup to inject secrets using a 1Password Service Account. In this example, the Kubernetes Injector injects secrets into APP_1, but not APP_2.

deployment-specification.yaml

Was this page helpful?