Configuring authentication to TLS Protect Datacenter without storing secrets with JWT mapping¶

This is a secretless method for authenticating with TLS Protect Datacenter. With this method, you don't require an access token or password. This method is limited to TLS Protect Datacenter 22.4 or later.

The following example shows a cluster issuer resource that uses a Kubernetes ServiceAccount Token to authenticate to Venafi TLS Protect Datacenter.

Configuring the Kubernetes resources¶

1. Create a service account that the Venafi Connection can use to authenticate to Venafi TLS Protect Datacenter.

   apiVersion: v1
   kind: ServiceAccount
   metadata:
     name: application-team-1
     namespace: venafi
   

2. Give the venafi-connection service account the permission to create tokens for this service account.

   1. Create a role that allows the creation of service account tokens for application-team-1:

      apiVersion: rbac.authorization.k8s.io/v1
      kind: Role
      metadata:
        name: create-tokens-for-application-team-1
        namespace: venafi
      rules:
      - apiGroups: [ "" ]
        resources: [ "serviceaccounts/token" ]
        verbs: [ "create" ]
        resourceNames: [ "application-team-1" ]
      

   2. Link the controller's service account to the create-tokens-for-vault-sa role:

      apiVersion: rbac.authorization.k8s.io/v1
      kind: RoleBinding
      metadata:
        name: application-team-1-sa-rolebinding
        namespace: venafi
      roleRef:
        apiGroup: rbac.authorization.k8s.io
        kind: Role
        name: create-tokens-for-application-team-1
      subjects:
      - kind: ServiceAccount
        name: venafi-connection
        namespace: venafi
      

3. Create the Venafi Connection certificate request that has a reference to the Venafi Control Plane server and to the service account:

   apiVersion: jetstack.io/v1alpha1
   kind: VenafiConnection
   metadata:
     name: application-team-1-connection
     namespace: venafi
   spec:
     tpp:
       url: https://tpp1.example.com
   
       accessToken:
         - serviceAccountToken:
             name: application-team-1
             audiences: [ "tpp" ]
         - tppOAuth:
             authInputType: JWT
             clientId: cert-manager.io
             url: https://tpp1.example.com
   

Configuring Venafi Control Plane for TLS Protect Datacenter¶

In this example, it is assumed that your application teams have their own user account and policy folder in Venafi TPP.

1. In the TPP UI, create a user account and generate a strong random password.

   For more information on how to create a user account, see the TPP Administration Guide.

   Retain the username / password for later when you need to share it with the platform team or upload it to a secret store. You need to perform this step for every team that requires access to the Venafi TPP API server.

2. Create an application integration. Venafi Enhanced Issuer needs permission to manage certificates using the TLS Protect Datacenter API, which corresponds to the scope certificate:manage.

   Note

   Venafi Enhanced Issuer 0.11.0 and earlier also required the permission to revoke certificates, which corresponded to the scope certificate:manager;revoke. With Venafi Enhanced Issuer 0.12.0 and later, this permission is no longer needed.

   The following are the service account scopes required by different versions of Venafi Enhanced Issuer and Approver Policy Enterprise:

   • Venafi Enhanced Issuer 0.11.x or earlier requires the service account scope to be set to certificate:manage;revoke.

   • Venafi Enhanced Issuer 0.12.0 or later requires the service account scope to be set to certificate:manage.

   • Approver Policy Enterprise 0.15.x or earlier requires the service account scope to be set to certificate:manage;revoke.

   • Approver Policy Enterprise 0.16.0 or later requires the service account scope to be set to certificate:manage.

   If you will be using the Contact feature, which allows you to configure the email contacts to be notified per certificate resource or per issuer resource, you will need to give the permission to manage certificates as well as the permission to read configuration. The corresponding scope is certificate:manage;configuration. You can learn more about the contact feature on the page Configuring email contacts when requesting certificates.

   For more information on API integrations, see the TPP Administration Guide.

3. Next, create a policy folder in the Policy Tree.

   For more information on adding objects to the Policy Tree, see the TLS Protect Datacenter Administration Guide.

4. Grant the user you created in Step 1 the following permissions: Write and Create.

   For more information on assigning permissions to an object in Policy Tree, see the TLS Protect Datacenter Administration Guide.

Create a JWT mapping¶

1. In the TLS Protect Datacenter UI, go to Platform > API > Default Settings, and click the JSON web token (JWT) checkbox.

   You need to create one JWT Mapping for each user account and per Kubernetes cluster. You need to know the issuer URL of the given Kubernetes cluster. You can find that by running the following command:

   kubectl get --raw /.well-known/openid-configuration | jq .issuer -r
   

   In the screenshot below, the issuer URL is https://storage.googleapis.com/test_oidc_endpoint/

2. In the Venafi Configuration Console, create the JWT mapping:

   1. Enter a Name. In the example below, the Kubernetes cluster name cluster-a with the Kubernetes service account name application-team-1 are used.
   2. Set the Audience field to aud and the Must match field to tpp. You need to set this same value when you configure the Venafi Connection.

   3. Set the Subscriber field to sub. The value must match the name of the Kubernetes service account you use in Venafi Connection. The format of the name is as follows:

      system:serviceaccount:<namespace>:<service-account-name>
      

      Put all of the Kubernetes service accounts meant to be used with the Venafi Connection in the namespace venafi.

      

      Note

      The map to field is evaluated as a RegEx (regular expression), not as a string. For more information, see About JWT Mappings.