Authenticate to Next-Gen Trust Security with Workload Identity Federation¶
In this tutorial, you'll configure Connection for Next-Gen Trust Security (Connection resource) to authenticate using Workload Identity Federation (WIF). With WIF, Kubernetes acts as an OIDC provider and issues ServiceAccount tokens that Next-Gen Trust Security (NGTS) validates.
Once these steps are complete, Connection resource will be able to authenticate to NGTS on behalf of your cluster components, such as Discovery Agent, Distributed Issuer, and Enterprise Issuer.
Prerequisites¶
Before you begin, prepare your environment and create a Built-in Account in NGTS with your cluster's OIDC provider details.
Prepare your environment¶
To configure Connection resource, you need:
- Access to an NGTS tenant.
kubectland jq installed on your workstation.- The Connection resource custom resource definition (CRD) installed in your cluster. To confirm, run
kubectl get crd venaficonnections.jetstack.io. If not present, see Installing Connection for Next-Gen Trust Security using Helm. - If your Built-in Account belongs to a workspace, Connection resource v0.7.0 or later.
Create a Built-in Account¶
Create a Built-in Account in NGTS with Workload Identity Federation authentication. Choose the Use Case and Scope for your component as follows:
- Discovery Agent: Select the
Discovery AgentUse Case andKubernetes DiscoveryScope. - Distributed Issuer: Select the
Distributed IssuerUse Case andDistributed IssuanceScope. - Enterprise Issuer: Select the
cert-manager Enterprise IssuerUse Case and Scope.
Supply the following OIDC details:
- Issuer URL: Your cluster's issuer URL. To get it, run
kubectl get --raw /.well-known/openid-configuration | jq -r '.issuer' -
JWKS URI: Your cluster's JWKS URI. To get it, run
kubectl get --raw /.well-known/openid-configuration | jq -r '.jwks_uri'The JWKS URI must be publicly accessible
NGTS must be able to reach the JWKS URI to validate tokens. If required, replicate your JWKS data to a public location and keep it synchronized.
-
Subject Identifier: The fully-qualified Kubernetes ServiceAccount in the format
system:serviceaccount:<namespace>:<service-account-name>. For example,system:serviceaccount:venafi:workload-identity-sa. - Audience: Your tenant's NGTS API URL, for example
https://<tsgID>.ngts.paloaltonetworks.com.
From your Built-in Account details, save these values for Step 2:
- Tenant Service Group ID: The
tsgID, for example0000000000. - Workspace ID: Needed only if the Built-in Account belongs to a workspace. On the Built-in Accounts page in NGTS, click the account. If the panel shows a workspace other than Tenant, copy its Workspace ID. Don't use the ID in the token URL, which belongs to the workspace you have selected in NGTS.
Step 1: Configure the service account¶
Create a Kubernetes ServiceAccount and grant the Connection resource controller permission to request tokens for it.
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 ServiceAccount that the Connection resource will use for authentication:
workload-identity-sa.yamlapiVersion: v1 kind: ServiceAccount metadata: name: workload-identity-sa # (1)! namespace: venafi- This value is included in the Subject field of the Built-in Account in NGTS, in the format
system:serviceaccount:venafi:workload-identity-sa.
Apply the manifest:
kubectl apply -f workload-identity-sa.yaml - This value is included in the Subject field of the Built-in Account in NGTS, in the format
-
Create a Role that grants the Connection resource permission to create tokens for the ServiceAccount:
workload-identity-role.yamlapiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: name: create-tokens-for-workload-identity-sa namespace: venafi rules: - apiGroups: [""] resources: ["serviceaccounts/token"] verbs: ["create"] resourceNames: ["workload-identity-sa"]Apply the manifest:
kubectl apply -f workload-identity-role.yaml -
Create a RoleBinding that binds the Role to the Connection resource controller:
workload-identity-rolebinding.yamlapiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: workload-identity-sa-token-rolebinding namespace: venafi roleRef: apiGroup: rbac.authorization.k8s.io kind: Role name: create-tokens-for-workload-identity-sa subjects: - kind: ServiceAccount name: venafi-connection namespace: venafiApply the manifest:
kubectl apply -f workload-identity-rolebinding.yaml
Step 2: Create the connection resource¶
Create a Connection resource that authenticates to NGTS using the ServiceAccount configured in Step 1.
-
Create the Connection resource:
ngts-connection.yamlapiVersion: jetstack.io/v1alpha1 kind: VenafiConnection metadata: name: ngts-connection namespace: venafi spec: ngts: tsgID: "<your-tsgID>" # (1)! # workspaceID: "<your-workspace-ID>" (2) jwt: - serviceAccountToken: # (3)! name: workload-identity-sa # (4)! audiences: ["<audience-configured-on-built-in-account>"] # (5)!- Replace with your Tenant Service Group ID.
- If the Built-in Account belongs to a workspace, uncomment this line and replace the placeholder with your workspace ID. See About authentication.
- Requests a ServiceAccount token from the Kubernetes TokenRequest API and sends it to NGTS.
- Must match the ServiceAccount created above and the Subject configured in your Built-in Account.
- Must match the Audience configured in your Built-in Account.
Apply the manifest:
kubectl apply -f ngts-connection.yaml
Related links¶
- Authenticate with a private key
- About cross-namespace access for Connection resource
- Connection resource API reference
- Troubleshooting Built-in Account authentication
- About workspaces in the Next-Gen Trust Security documentation