Deliver X.509-SVID certificates with Secrets Operator

Aembit Secrets OperatorAembit Secrets Operator: Aembit Secrets Operator is a Kubernetes operator that authenticates to the Aembit platform and synchronizes credentials into Kubernetes Secrets for applications to consume directly.Learn more (ASO) can deliver X.509-SVIDX.509-SVID: A SPIFFE Verifiable Identity Document in X.509 certificate format. X.509-SVIDs are certificates that embed a workload's SPIFFE ID as a URI Subject Alternative Name (SAN) and enable mutual TLS authentication between workloads. Aembit issues SVIDS with short lifetimes and automatic rotation.Learn more certificates to your Kubernetes workloads. When a schedule uses the X.509-SVID Credential Provider, Secrets Operator generates a private key inside the cluster and obtains a signed certificate from Aembit. It writes both into a standard Kubernetes kubernetes.io/tls Secret that your workload consumes for mTLSmTLS: Mutual Transport Layer Security. A TLS handshake in which both the client and server present certificates and validate each other's identity before any application traffic flows. mTLS is commonly used for workload-to-workload authentication where both parties must prove identity at the transport layer.Learn more.

Secrets Operator generates the private key in-cluster, and the key never leaves the cluster. Secrets Operator sends only a certificate signing request to Aembit for signing, and refreshes the certificate automatically before it expires.

How certificate delivery works

1. Generate the key in-cluster: Secrets Operator generates a private key and a certificate signing request inside the cluster. The private key stays in the cluster and is never transmitted to Aembit.

2. Sign the certificate: Secrets Operator requests a certificate from Aembit for the Access PolicyAccess Policy: Access Policies define, enforce, and audit access between Client and Server Workloads by cryptographically verifying workload identity and contextual factors rather than relying on static secrets.Learn more that applies to it. Aembit signs an X.509-SVID certificate and returns the signed certificate chain. The chain holds the leaf certificate and any intermediates. The Aembit root Certificate Authority (CA) isn’t included, so the Server Workload the certificate authenticates to must already trust the issuing Aembit Standalone CA.

3. Write to the Secret: Secrets Operator writes the signed chain to tls.crt and the in-cluster private key to tls.key in a kubernetes.io/tls Secret. Secrets Operator creates the Secret if it doesn’t exist.

4. Consume the certificate: Your workload reads the certificate and key from the Secret using standard Kubernetes mechanisms, such as a volume mount or environment variables.

5. Refresh automatically: Secrets Operator generates a new key and requests a new certificate before the current one expires, then updates the Secret. By default, it refreshes at 80% of the certificate’s lifetime.

Prerequisites

Before you begin, make sure you have:

• Secrets Operator installed in your cluster with a working AembitEdgeApiClient. See Set up Secrets Operator to install and configure it.
• An X.509-SVID Credential Provider in your Aembit tenant. See Create an X.509-SVID Credential Provider.
• An Access Policy that binds the Secrets Operator Client Workload to the X.509-SVID Credential Provider.

Configure the certificate identity in the tenant

You configure the certificate’s identity and constraints on the Credential Provider, not on the Secrets Operator schedule. Configure the following on the X.509-SVID Credential Provider in your Aembit tenant:

• The SPIFFE ID that Aembit embeds as the certificate’s URI Subject Alternative Name.
• The certificate lifetime.
• The Extended Key Usage (EKU) values that control which side of the TLS handshake the certificate can authenticate.

For the meaning of each option, see About the X.509-SVID Credential Provider. The Secrets Operator schedule doesn’t set any of these values—it only selects the Credential Provider type.

Create the certificate schedule

Create an AembitSecretRefreshSchedule that sets credentialType to X509Svid. This is the only field that differs from a token schedule.

1. Save the following manifest as x509-svid-schedule.yaml, replacing the server.host and server.port values with the details of the Server Workload the certificate authenticates to:

   x509-svid-schedule.yaml

   apiVersion: aembit.io/v1
   kind: AembitSecretRefreshSchedule
   metadata:
     name: x509-svid-schedule
     namespace: aembit-system
   spec:
     aembitEdgeApiClientRef:
       name: aembit-connection
     targetSecretName: workload-tls
     credentialType: X509Svid
     server:
       host: api.example.com
       port: 443
     # refreshInterval: "4h"  # Optional: omit to refresh at 80% of the certificate lifetime

2. Apply the manifest to create the schedule:

   kubectl apply -f x509-svid-schedule.yaml

For the full field reference, see Credential types and Secret data keys.

The Secret is created in the schedule’s namespace

Secrets Operator writes the target Secret to the same namespace as the AembitSecretRefreshSchedule. Because Kubernetes Secrets can’t be mounted across namespaces, create the schedule and its AembitEdgeApiClient in the same namespace as the workload that consumes the certificate.

Switching credentialType recreates the Secret

A Kubernetes Secret’s type is immutable. Switching an existing schedule’s credentialType to or from X509Svid changes the target Secret’s type between a generic Secret and a kubernetes.io/tls Secret, so Secrets Operator deletes and recreates the Secret. Any workload mounting the Secret sees it briefly disappear and reappear.

Verify the certificate

Confirm Secrets Operator issued the certificate and wrote it to the Secret.

1. Check the schedule status:

   kubectl describe aembitsecretrefreshschedule x509-svid-schedule --namespace aembit-system

   A healthy schedule reports the Ready phase and a populated credentialExpiresAt.

2. Confirm the Secret exists and has the kubernetes.io/tls type with tls.crt and tls.key keys:

   kubectl get secret workload-tls --namespace aembit-system \
     --output jsonpath='{.type}{"\n"}{range $k, $v := .data}{$k}{"\n"}{end}'

   kubernetes.io/tls
   tls.crt
   tls.key

Consume the certificate from a workload

Mount the Secret into your workload the same way you consume any kubernetes.io/tls Secret. Add it as a volume in your workload’s pod spec so your application reads the certificate and key from files. The following excerpt shows the relevant spec fields of a Pod (use the same fields under spec.template.spec in a Deployment):

Pod spec excerpt

spec:
  containers:
    - name: app
      volumeMounts:
        - name: workload-tls
          mountPath: /etc/tls
          readOnly: true
  volumes:
    - name: workload-tls
      secret:
        secretName: workload-tls

Your application reads the certificate from /etc/tls/tls.crt and the private key from /etc/tls/tls.key. Secrets Operator refreshes the certificate in place. Mount the Secret as a volume rather than injecting it as environment variables, so your workload picks up rotated material without a restart.

The Secret contains no trust bundle

The Secret holds only tls.crt and tls.key—the workload’s own certificate and private key. It doesn’t include a ca.crt key. If your workload also needs to verify the certificate of the server it connects to, provide that server’s CA through a ConfigMap or other trust source.

Limitations

• No certificate revocation: Aembit doesn’t publish Certificate Revocation Lists or Online Certificate Status Protocol responders for X.509-SVID certificates. Short certificate lifetimes and automatic rotation are the primary controls.
• No service mesh integration: Secrets Operator delivers certificates to Kubernetes Secrets only. It doesn’t integrate with Envoy Secret Discovery Service (SDS) or Istio sidecar certificate provisioning. For transparent mesh-style mTLS, use Agent Proxy instead.
• Chain excludes the root CA: The delivered chain contains the leaf certificate and any intermediates, but not the Aembit root CA. The Server Workload must already trust the issuing Aembit Standalone CA.

Next steps

• About the X.509-SVID Credential Provider: How X.509-SVID certificates work and how to choose between consumers.
• Enable mTLS on a Server Workload: Configure the Server Workload that authenticates the certificate.
• Secrets Operator Configuration Reference: CRD fields, status fields, and Secret data keys.