Automate Kubernetes Security with Go Operators for Vault and Cert-Manager

Kubernetes clusters often drown teams in repetitive YAML configurations for security, ingress, and service setup. When you remove cloud provider abstractions, this problem intensifies—each component requires manual manifests for custom resources, roles, and policies. The solution lies in creating self-service operators that encapsulate these patterns into simple declarations.

In Part 2 of this series, we explore two open-source Go operators designed to bridge Kubernetes with HashiCorp Vault and certificate management systems like Cert-Manager. These operators automate the boilerplate of security configurations, allowing developers to request TLS certificates or secrets without touching Vault’s API or Kubernetes RBAC directly.

Why Platform Teams Need Self-Service Operators

Manual Vault integrations follow a repetitive pattern that introduces friction:

• Creating Kubernetes ServiceAccounts
• Defining Vault Roles tied to those accounts
• Writing Vault Policies and binding them to roles
• Generating JWT tokens for authentication

This process is mandatory for secure cross-cluster communication but becomes unwieldy when repeated for every application. Instead of requiring platform engineers to repeat these steps, operators like vaultreaver and platform-operator automate the entire workflow. They act as intermediaries, handling the complexity of Vault’s Kubernetes authentication backend while exposing clean APIs for developers.

How vaultreaver Streamlines Vault Security

The vaultreaver operator focuses on managing Vault’s external resources—policies, roles, and bindings—via Kubernetes Custom Resource Definitions (CRDs). It introduces two key CRDs to simplify security declarations:

• `VaultPolicy`: Defines a Vault policy with granular permissions, such as read access to a specific secret path.
• `VaultKubernetesRoleBinding`: Links a Vault policy to a Kubernetes ServiceAccount, binding it to a Vault role with a defined token TTL.

Consider a scenario where an Nginx deployment needs to read secrets from Vault’s kv engine. Instead of manually configuring these resources, the operator consumes a declarative manifest:

apiVersion: security.platform.io/v1alpha1
kind: VaultPolicy
metadata:
  name: nginx-deployment-external-secret
  namespace: nginx-apps
spec:
  policy: |
    path "kv/data/app-teste/secret-secreto" {
      capabilities = ["read"]
    }
  vaultPolicyName: nginx-deployment-external-secret-policy
---
apiVersion: security.platform.io/v1alpha1
kind: VaultKubernetesRoleBinding
metadata:
  name: nginx-deployment-external-secret
  namespace: nginx-apps
spec:
  audience: vault
  authMount: kubernetes
  boundNamespaces:
    - nginx-apps
  boundServiceAccounts:
    - nginx-deployment-external-secret
  roleName: nginx-deployment-external-secret
  tokenPolicies:
    - nginx-deployment-external-secret-policy
  tokenTTL: 1h

Once vaultreaver applies these resources, it generates a JWT token for the ServiceAccount, enabling secure authentication with Vault’s API. This token is automatically injected into the application’s environment, eliminating manual secret provisioning.

platform-operator: Simplifying TLS and External Secrets

While vaultreaver handles Vault-side configurations, the platform-operator manages in-cluster automation. Its API abstracts complex workflows into single Custom Resources (CRs), focusing on developer experience rather than infrastructure details.

One of its key features is simplifying TLS certificate provisioning via Cert-Manager and Vault’s PKI backend. Developers define a VaultCertificate CR with their requirements:

apiVersion: security.platform.io/v1alpha1
kind: VaultCertificate
metadata:
  name: nginx-deployment-tls
  namespace: nginx-apps
spec:
  vaultUrl: 
  authPath: /v1/auth/kubernetes
  vaultRole: nginx-deployment-tls-role
  pkiPath: pki/sign/internal-dot-infra
  commonName: my-app.internal.infra
  dnsNames:
    - my-app.internal.infra
    - my-app-teste.internal.infra
  secretName: nginx-deployment-tls
  certManagerServiceAccount: cert-manager
  certManagerNamespace: cert-manager

Under the hood, the operator dynamically generates:

• A ServiceAccount with the required RBAC permissions
• A Cert-Manager ClusterIssuer or Issuer configured for Vault
• The final Certificate CR that triggers TLS issuance

Similarly, the operator automates ExternalSecrets workflows by creating SecretStore and ExternalSecret resources from a clean interface, removing the need for developers to write these manifests manually.

Validating the Solution in a Real-World Lab

To ensure reliability, we built a full lab environment replicating production scenarios. The setup demonstrates:

• Automated TLS certificate provisioning via Cert-Manager and Vault
• Secure secret injection into applications using ExternalSecrets
• End-to-end validation of Nginx deployments with TLS-encrypted ingress

The lab serves as both a proof of concept and a reference implementation, available in a public repository for teams to adapt. By automating these workflows, platform engineers can reduce configuration drift and empower developers to provision infrastructure safely and independently.

As Kubernetes adoption grows, so does the demand for self-service platforms. Operators like these transform sprawling YAML forests into manageable APIs, shifting the burden from manual configuration to automated governance.