Posted inDevOps

Stop Storing Secrets in Git: A Guide to 1Password Connect on Kubernetes

DevOps tutorial - IT technology blog
DevOps tutorial - IT technology blog

Beyond Base64: Why Your Secret Strategy Needs an Upgrade

Most Kubernetes journeys begin with the built-in Secret resource. While easy to use, native secrets are just Base64-encoded strings, not encrypted data. Relying on them without extra configuration is like putting your house keys under a transparent welcome mat. I have seen teams struggle with “secret sprawl,” where sensitive API keys end up leaked in Git history or hardcoded in CI/CD pipelines.

When moving to a centralized model, you generally face three choices:

  • Native Kubernetes Secrets: These are simple but lack audit trails. Storing them in Git—even via tools like SealedSecrets—creates a clunky workflow where developers can’t easily see what’s currently deployed.
  • HashiCorp Vault: This is the heavy hitter for high-security environments. However, the operational tax is high. You need a dedicated team to manage unseal keys, handle storage backends, and navigate complex HCL policies.
  • 1Password Connect: This serves as a sync layer between a user-friendly password manager and your automated infrastructure. It allows DevOps teams to use the 1Password UI they already know while programmatically pushing those secrets into Kubernetes.

I have deployed this setup in production environments ranging from small startups to mid-sized enterprises. It consistently hits the sweet spot between developer productivity and strict security requirements.

The Real-World Trade-offs

No tool is perfect for every scenario. 1Password Connect is often the “Goldilocks” solution for teams that want security without the overhead of a full Vault cluster.

The Pros

  • Human-Friendly UI: Security auditors can review access in a clean web interface. They don’t need to learn kubectl or decode strings in their terminal.
  • Instant Propagation: When a developer updates a database password in the 1Password app, the change hits the Kubernetes cluster in about 10 seconds.
  • Isolation: You can restrict the integration to specific “Vaults.” This ensures your production cluster never even sees personal or administrative credentials.

The Cons

  • External Dependency: If 1Password’s global API goes offline, you cannot sync new secrets. However, your existing secrets stay cached in the cluster, so your apps won’t crash.
  • Resource Footprint: You must run two small containers. In my experience, these typically consume less than 150MB of RAM combined, which is negligible for most clusters.

A Production-Ready Architecture

Under the hood, the system relies on two main components provided by 1Password:

  1. Connect Server: A deployment containing the connect-api and connect-sync containers. This acts as the secure gateway between your cluster and 1Password’s servers.
  2. 1Password Operator: A Kubernetes controller that watches for a Custom Resource Definition (CRD) called OnePasswordItem. It automatically generates native Kubernetes secrets based on your 1Password data.

I recommend deploying these into a dedicated 1password-system namespace. Use strict RBAC policies to ensure only authorized service accounts can talk to the Connect API.

Step-by-Step: Deploying 1Password Connect

1. Generate the Credentials

Start in your 1Password developer dashboard. Create a new “Connect” integration and select the specific Vaults you want to share. You will receive a 1password-credentials.json file and an Access Token. Treat these like your root password; if they are compromised, your entire secret store is at risk.

2. Deploy the Connect Server

Helm is the fastest way to get running. First, create the namespace and a secret to hold your integration file.

kubectl create namespace 1password-system

# Securely upload your credentials file
kubectl create secret generic op-credentials \
  --from-file=1password-credentials.json=./1password-credentials.json \
  -n 1password-system

# Add the official repository
helm repo add 1password https://1password.github.io/connect-helm-charts/
helm repo update

Now, install the Connect server. Replace the placeholder with your actual Access Token.

helm install connect 1password/connect \
  --namespace 1password-system \
  --set-file connect.credentials=1password-credentials.json \
  --set connect.token.value="your-token-here"

3. Install the 1Password Operator

The Operator handles the logic of transforming 1Password items into Kubernetes secrets. Installing it separately keeps your management logic clean.

helm install operator 1password/onepassword-operator \
  --namespace 1password-system \
  --set connect.url="http://connect.1password-system.svc.cluster.local:8080" \
  --set connect.token="your-token-here"

4. Syncing Your First Secret

Instead of manual YAML secrets, you now define a OnePasswordItem. This manifest points the Operator to the exact item in your vault.

apiVersion: onepassword.com/v1
kind: OnePasswordItem
metadata:
  name: db-credentials
  namespace: default
spec:
  itemPath: "vaults/Production/items/Database"
  outputs:
    - name: password
      path: "fields/password"
    - name: username
      path: "fields/username"

Apply this YAML. Within seconds, the Operator creates a standard Kubernetes Secret named db-credentials. Your application can mount this as an environment variable or a volume without ever knowing 1Password exists.

Hard-Won Lessons from the Field

Running this in production taught me a few critical lessons about reliability and security.

Segment Your Vaults

Never connect a “General” vault to Kubernetes. Create environment-specific vaults like K8S-Staging or K8S-Prod. This limits the “blast radius” if a cluster is ever compromised.

Monitor the Sync Health

If your token expires or the network blips, secret updates will fail silently. I recommend setting up Prometheus alerts for the op_connect_sync_errors_total metric. If this value stays above zero for more than five minutes, your team needs to investigate.

Leverage Version History

1Password keeps a full history of every change. If a database migration goes sideways because of a credential change, you can revert the item in the 1Password UI. The Operator will sync the previous value back to the cluster in under 15 seconds, potentially saving you from a long outage.

Lock Down RBAC

Restrict who can create OnePasswordItem resources. If a malicious user can create these in a namespace, they could theoretically pull any secret from the vaults linked to that Connect instance.

Final Thoughts

Managing secrets shouldn’t be a manual chore. By using 1Password Connect, you give your developers a familiar tool while maintaining a high security bar. It effectively eliminates the need to store secrets in Git and provides a clear, searchable audit trail for every credential in your stack.

Share:
Tags: