Authenticate to Next-Gen Trust Security with a Built-In Account¶
In this tutorial, you'll configure Enterprise Issuer to authenticate with Next-Gen Trust Security using a Built-In Account. By the end, your cluster will be able to request and issue certificates from Next-Gen Trust Security without managing long-lived credentials.
Built-In Accounts use private key JWT authentication with automatic OAuth token exchange, so you don't need to manage or rotate API keys.
Prerequisites¶
Complete pre-configuration¶
Complete the following steps in Next-Gen Trust Security:
-
Create a Built-In Account with the cert-manager Enterprise Issuer Use Case and Scope. Save the following credentials:
- Private key: Only shown at account creation.
- Client ID: For example,
d1ee9403-3f04-11f1-9e5d-ce934f0fad3f. - Tenant Service Group ID: From your user profile at bottom left. For example,
1722931406.
-
Create an Issuing Template.
Prepare your environment¶
To configure Connection for Next-Gen Trust Security you need:
- Access to a Next-Gen Trust Security tenant.
kubectlinstalled on your workstation.-
A Kubernetes cluster with Enterprise Issuer installed.
Verify that Enterprise Issuer is installed
To verify Enterprise Issuer, run:
kubectl get pods -n venafiThe Enterprise Issuer pod should show
Running. If not, see Troubleshooting Enterprise Issuer. -
The Connection for Next-Gen Trust Security custom resource definition (CRD) installed in your cluster.
- If you installed Enterprise Issuer with default Helm values, the CRD is already included.
- If you set
venafiConnection.includetofalsein the Enterprise Issuer Helm values, install the CRD separately.
Step 1: Configure the Kubernetes resources¶
Store your Built-In Account private key in a Kubernetes Secret, then create a VenafiConnection that uses it to authenticate to Next-Gen Trust Security.
About cross-namespace access
These steps use the venafi namespace, which is the recommended location. To use application namespaces instead, enable cross-namespace access with allowReferencesFrom.
-
Create a Kubernetes Secret containing your Built-In Account private key:
ngts-credentials-secret.yamlapiVersion: v1 kind: Secret metadata: name: ngts-credentials namespace: venafi stringData: privateKey: | -----BEGIN EC PRIVATE KEY----- <your private key content> -----END EC PRIVATE KEY-----Apply the manifest:
kubectl apply -f ngts-credentials-secret.yaml -
Create a Role that grants the Connection resource read access to the
ngts-credentialsSecret:ngts-credentials-role.yamlapiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: name: get-ngts-credentials namespace: venafi rules: - apiGroups: [""] resources: ["secrets"] verbs: ["get"] resourceNames: ["ngts-credentials"]Apply the manifest:
kubectl apply -f ngts-credentials-role.yaml -
Create a RoleBinding that binds the Role to the Connection resource controller:
ngts-credentials-rolebinding.yamlapiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: ngts-credentials-rolebinding namespace: venafi roleRef: apiGroup: rbac.authorization.k8s.io kind: Role name: get-ngts-credentials subjects: - kind: ServiceAccount name: venafi-connection namespace: venafiApply the manifest:
kubectl apply -f ngts-credentials-rolebinding.yaml -
Create a Connection resource that authenticates to Next-Gen Trust Security using the Built-In Account private key:
ngts-connection.yamlapiVersion: jetstack.io/v1alpha1 kind: VenafiConnection metadata: name: ngts-connection namespace: venafi spec: ngts: tsgID: "<your-tsgID>" # (1)! jwt: # (2)! - secret: # (3)! name: ngts-credentials fields: - privateKey - privateKeyJWT: # (4)! clientID: "<your-client-id>"- Replace with your Tenant Service Group ID.
- Defines a two-step authentication chain.
- Reads the private key from the Kubernetes Secret.
- Signs a JSON Web Token (JWT) and exchanges it for an OAuth bearer token.
Apply the manifest:
kubectl apply -f ngts-connection.yaml
Step 2: Configure Enterprise Issuer¶
-
Create a
VenafiIssuerorVenafiClusterIssuerresource that references the Connection resource. UseVenafiIssuerfor a single namespace, orVenafiClusterIssuerfor cluster-wide access:ngts-issuer.yaml1. ReplaceapiVersion: jetstack.io/v1alpha1 kind: VenafiIssuer metadata: name: ngts-issuer namespace: venafi spec: venafiConnectionName: ngts-connection zone: "Issuing Template Name" # (1)!Issuing Template Namewith the value from your prerequisites.Apply the manifest:
kubectl apply -f ngts-issuer.yaml
Step 3: Request a certificate¶
-
Create a cert-manager Certificate resource that references the
VenafiIssuerresource:example-cert.yamlapiVersion: cert-manager.io/v1 kind: Certificate metadata: name: example-cert namespace: venafi spec: secretName: example-cert-tls commonName: example.com dnsNames: - example.com - www.example.com issuerRef: name: ngts-issuer kind: VenafiIssuer group: jetstack.ioApply the manifest:
kubectl apply -f example-cert.yamlOnce applied, cert-manager requests a certificate from Next-Gen Trust Security through Enterprise Issuer and Connection resource.
Step 4: Verify certificate issuance¶
-
Check the status of the certificate:
kubectl get certificate example-cert -n venafiWhen the certificate has been issued, the
READYcolumn showsTrue:NAME READY SECRET AGE example-cert True example-cert-tls 30sIf the certificate isn't ready after a few minutes, inspect the resources and see Troubleshooting Built-In Account authentication.
-
To verify the issued certificate, inspect the leaf certificate in the Secret:
kubectl get secret example-cert-tls -n venafi -o jsonpath='{.data.tls\.crt}' | base64 -d | openssl x509 -text -nooutVerify the Subject, Issuer, and Subject Alternative Names.