Venafi Connection authentication to Venafi¶

Venafi Connection has a flexible mechanism for loading the bearer token which it uses to interact with Venafi API endpoints.

You can load the bearer token (also known as the access token) directly from a Kubernetes secret, or if you prefer to minimize the use of Kubernetes secret resources, you can configure Venafi Connection to dynamically generate tokens using ephemeral Kubernetes service account tokens or load the access token (or the associated OAuth credentials) from HashiCorp Vault. Controllers that use Venafi Connections can authenticate to HashiCorp Vault using an ephemeral Kubernetes service account token, which it generates dynamically rather than loading it from a secret or from a project service account token volume.

You define a chain of one or more authentication steps in the accessToken field of the Venafi Cluster Issuer or Venafi Issuer resource. The output of each step in the chain is the input to the next step until the output of the final step. The output of the final step must be the Venafi bearer token which is used to authentication to the Venafi resource APIs for posting certificate signing requests, and later downloading the signed certificates.

You can configure Venafi Connection to load either the access token directly from a source (assuming that you have created and stored the access token out-of-band using vcert getcred, for example). Or, you can configure Venafi Connection to load a username / password from a Kubernetes secret or a HashiCorp Vault secret, and then use that to authenticate to the Venafi auth APIs in return for a bearer token.

Related links¶

• Use SA JWT token authentication
• Use Kubernetes Secret authentication
• Use HashiCorp Vault authentication