Managing Venafi TPP OAuth credentials for TLS Protect for Kubernetes
In this course, we will install venafi-oauth-helper into a Kubernetes cluster and connect it to a Venafi TPP instance.
venafi-oauth-helper is an operator to manage the Kubernetes secrets that contain an OAuth access-token used by the Venafi TPP Issuer in cert-manager.
Overview
venafi-oauth-helper reads bootstrap credentials from a Kubernetes Secret. The Secret containing the bootstrap credentials must have a particular name and an annotation so that venafi-oauth-helper knows how to find it.
venafi-oauth-helper can be bootstrapped using username-password, client-certificate, or refresh-token credentials.
venafi-oauth-helper uses the bootstrap credentials to authenticate with a TPP server, and it receives an access-token and a refresh-token and saves those to two new Kubernetes Secrets.
cert-manager can then read the access-token Secret and uses it to authenticate to the resource API of the TPP server.
venafi-oauth-helper periodically verifies the access-token and if it has expired it renews it. By default, the access-token is verified every minute, but you can change the interval with the command-line option: --access-token-verify-interval.
If an access-token is revoked by the TPP server administrator, venafi-oauth-helper will automatically renew the token within one minute (or --access-token-verify-interval).
Background
Venafi TPP has an authentication API which accepts a username-password or a client-certificate or a refresh-token in exchange for an access-token and a new refresh-token. The access-token can then be used in subsequent calls to the resource API.
ℹ️ A username-password or client-certificate may have been issued to you by the TPP administrator.
It is important to understand the different levels of access afforded by each of these different credential types.
A username-password allows full access to all the services granted to their owner. If it is leaked, it would allow an attacker to access the TPP web UI, the authentication API and thereby access to the resource API. It can only be revoked by an administrator removing the account or by changing the account password.
A client-certificate allows access to the authentication API and thereby access to the resource API, and may also allow access to the TPP web UI, depending on whether the TPP administrator has configured client certificate authentication in IIS. It can be revoked by an administrator updating a revocation list or by changing the trusted CA certificate.
A refresh-token allows time-limited access to a single authentication API endpoint. The refresh-token will always result in an access-token with the same scope as the original. It can not be exchanged for an access-token with greater privileges. refresh-token is a one-time-use credential which means that if it is leaked and used, the breach will be detected as soon as the legitimate application attempts to use the same refresh-token. Each time the refresh-token is used, a new refresh-token is issued, and so it must be stored by the application until it is needed. A refresh-token typically has a much longer time-limit than an access-token, so it may still valid long after the associated access-token has expired.
An access-token allows time-limited access to a subset of the resource API. It can be scoped to only allow a subset of VERBS on a subset of resource API endpoints. It has a time-limit and it can easily be revoked without affecting other access-tokens issued from the same account. If it is leaked, it would allow an attacker limited access to the resource API for a limited time, or until it is revoked.
ℹ️ In TPP 20.4 the minimum access-token lifetime is 1 day and in newer versions of TPP the minimum access-token lifetime is 1 hour.
ℹ️ The refresh-token lifetime should be much higher to avoid repeated bootstrapping and to avoid unnecessarily loading and transmitting the bootstrap-credentials when using username-password or client-certificate.