Skip to content

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.
  • kubectl and 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 Agent Use Case and Kubernetes Discovery Scope.
  • Distributed Issuer: Select the Distributed Issuer Use Case and Distributed Issuance Scope.
  • Enterprise Issuer: Select the cert-manager Enterprise Issuer Use 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 example 0000000000.
  • 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.

  1. Create a Kubernetes ServiceAccount that the Connection resource will use for authentication:

    workload-identity-sa.yaml
    apiVersion: v1
    kind: ServiceAccount
    metadata:
      name: workload-identity-sa # (1)!
      namespace: venafi
    
    1. 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
    
  2. Create a Role that grants the Connection resource permission to create tokens for the ServiceAccount:

    workload-identity-role.yaml
    apiVersion: 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
    
  3. Create a RoleBinding that binds the Role to the Connection resource controller:

    workload-identity-rolebinding.yaml
    apiVersion: 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: venafi
    

    Apply 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.

  1. Create the Connection resource:

    ngts-connection.yaml
    apiVersion: 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)!
    
    1. Replace with your Tenant Service Group ID.
    2. If the Built-in Account belongs to a workspace, uncomment this line and replace the placeholder with your workspace ID. See About authentication.
    3. Requests a ServiceAccount token from the Kubernetes TokenRequest API and sends it to NGTS.
    4. Must match the ServiceAccount created above and the Subject configured in your Built-in Account.
    5. Must match the Audience configured in your Built-in Account.

    Apply the manifest:

    kubectl apply -f ngts-connection.yaml