Managing Secrets Securely in Kubernetes with 1Password

Managing secrets securely in Kubernetes is a critical challenge for modern cloud-native environments. Application credentials, certificates, private keys, and passwords must be handled in a way that is secure, auditable, and operationally flexible – especially when regular rotation is required.

By integrating 1Password with Kubernetes using the External Secrets Operator (ESO), teams can centralize secret management while keeping sensitive data out of Git repositories and Kubernetes manifests.

This approach enables Kubernetes workloads to consume secrets securely while maintaining strong access control and rotation practices.

Architecture Overview: 1Password + Kubernetes

The 1Password integration with Kubernetes works by introducing an abstraction layer between Kubernetes and the 1Password cloud API.

Instead of Kubernetes communicating directly with 1Password’s cloud service, a 1Password Connect Server runs inside the cluster. This design provides better security, performance, and control.

The flow looks like this:

1. Kubernetes communicates with the External Secrets Operator
2. ESO talks to the 1Password Connect Server inside the cluster
3. The Connect Server authenticates to 1Password using a token
4. Requested secrets are fetched and returned to Kubernetes

This architecture allows secrets to be synced securely into Kubernetes-native Secret objects.

Step 1: Install External Secrets Operator and Configure ClusterSecretStore

To begin, you must install the External Secrets Operator in your Kubernetes cluster. ESO provides the Custom Resource Definitions (CRDs) required to define how Kubernetes connects to external secret providers.

The most important CRD in this setup is the ClusterSecretStore. It is a cluster-wide resource that defines how Kubernetes authenticates and communicates with 1Password.

Example configuration:

kubectl get ClusterSecretStore/ie-onepassword -o yaml
apiVersion: external-secrets.io/v1
kind: ClusterSecretStore
spec:
  conditions:
  - namespaceSelector:
      matchLabels:
        bango.com/dept: Engineering
  provider:
    onepassword:
      auth:
        secretRef:
          connectTokenSecretRef:
            key: token
            name: onepassword-connect-token-ie
            namespace: ns-dev-external-secrets
      connectHost: http://onepassword-connect.ns-dev-1password-connect-server.svc.cluster.local:8080
      vaults:
        Engineering DevTest: 1

This configuration instructs ESO to communicate with the 1Password Connect Server rather than the public 1Password API. The Connect Pod authenticates using a token and retrieves secrets from the specified vault.

Step 2: Create ExternalSecret Resources for Applications

To consume secrets inside an application – for example, a service that uses a client certificate to authenticate to a remote endpoint – you must define an ExternalSecret resource.

Example:

apiVersion: external-secrets.io/v1
kind: ExternalSecret
metadata:
  labels:
    env: dev
  name: dev-cert-external-secrets-even
  namespace: ns-dev-engineering-korek
spec:
  data:
  - remoteRef:
      key: CERT Engineering|endpoint|Cert|dev 20260626
      property: endpoint_dev_CERT_PUBLIC.pem
    secretKey: CERT_PEM
  - remoteRef:
      key: CERT Engineering|endpoint|Key|dev 20260626
      property: endpoint_dev_KEY.key
    secretKey: CERT_PRIVKEY
  target:
    name: dev-external-secrets-even
    creationPolicy: Owner
    deletionPolicy: Retain

Key Concepts Explained

• remoteRef.property specifies the exact entry inside 1Password to be retrieved.
• Applications cannot reference ExternalSecret objects directly.
• The target section defines the Kubernetes Secret that ESO creates and keeps in sync.

This target secret is what applications ultimately consume.

Supporting Certificate Rotation with Even/Odd Secrets

To enable safe certificate and key rotation, it’s recommended to maintain two ExternalSecrets:

• dev-external-secrets-even
• dev-external-secrets-odd

This approach allows:

• Seamless certificate rotation
• Zero-downtime updates
• Easy rollbacks by switching references

When a rotation cycle is approaching, new certificates can be added to 1Password and synced to the inactive ExternalSecret without impacting the running application.

Understanding creationPolicy and deletionPolicy

Two fields require special attention:

creationPolicy: Owner

• ESO creates the Kubernetes Secret if it doesn’t exist
• ESO updates the Secret whenever the external value changes
• Deleting the ExternalSecret deletes the target Secret

Alternatively, Merge can be used when multiple controllers manage the same Secret.

deletionPolicy: Retain

• If a secret is accidentally removed from 1Password, the Kubernetes Secret remains
• Prevents accidental outages caused by human error
• Recommended for production workloads

Step 3: Verifying ExternalSecret Health

A healthy and synced ExternalSecret looks like this:

kubectl -n ns-dev-app get externalsecret
NAME                             STORETYPE            STORE            REFRESH INTERVAL   STATUS         READY
dev-app-external-secrets-even    ClusterSecretStore   ie-onepassword   5m                SecretSynced   True
dev-app-external-secrets-odd     ClusterSecretStore   ie-onepassword   5m                SecretSynced   True

Updating secrets in 1Password automatically updates the corresponding Kubernetes Secret without disrupting the application.

Step 4: Mount Multiple Secrets Using Projected Volumes

To make both certificate sets available in the same directory inside a container, you can use a projected volume. This allows multiple secrets to be mounted into a single path.

Example using Flux and Kustomize:

patch: |-
- op: add
  path: "/spec/template/spec/volumes/-"
  value:
    name: app-keystore-cert
    projected:
      sources:
      - secret:
          name: dev-app-external-secrets-odd
          items:
          - key: TEST_PEM
            path: app_keystore-odd.pem
          - key: TEST_PRIVKEY
            path: app_keystore-private-odd.pem
      - secret:
          name: dev-app-external-secrets-even
          items:
          - key: TEST_PEM
            path: app_keystore-even.pem
          - key: TEST_PRIVKEY
            path: app_keystore-private-even.pem

The final step is simply configuring the application to reference the appropriate file inside the container.

Final Thoughts

Using 1Password with Kubernetes via the External Secrets Operator provides a secure, flexible, and production-ready approach to secret management.

This setup enables:

• Centralized secret storage
• Safe certificate rotation
• Reduced blast radius from human error
• Kubernetes-native secret consumption

For teams operating at scale, this approach significantly improves both security posture and operational reliability.

Check out more of our blog posts here.