Vault as the Controller and Connect Inject Webhook Certificate Provider on Kubernetes
This topic describes how to configure the Consul Helm chart to use TLS certificates issued by Vault in the Consul controller and connect inject webhooks.
Overview
In a Consul Helm chart configuration that does not use Vault, webhook-cert-manager
ensures that a valid certificate is updated to the mutatingwebhookconfiguration
of either the controller or connect inject to ensure that Kubernetes can communicate with each of these services.
When Vault is configured as the controller and connect inject Webhook Certificate Provider on Kubernetes:
webhook-cert-manager
is no longer deployed to the cluster.- Controller and connect inject each get their webhook certificates from its own Vault PKI mount via the injected Vault Agent.
- Controller and connect inject each need to be configured with its own Vault Role that has necessary permissions to receive certificates from its respective PKI mount.
- Controller and connect inject each locally update its own
mutatingwebhookconfiguration
so that Kubernetes can relay events. - Vault manages certificate rotation and rotates certificates to each webhook.
To use Vault as the controller and connect inject Webhook Certificate Provider, we will need to modify the steps outlined in the Data Integration section:
These following steps will be repeated for each datacenter:
- Create a Vault policy that authorizes the desired level of access to the secret.
- (Added) Create Vault PKI roles for controller and connect inject that each establish the domains that each is allowed to issue certificates for.
- Create Vault Kubernetes auth roles that link the policy to each Consul on Kubernetes service account that requires access.
- Configure the Vault Kubernetes auth roles in the Consul on Kubernetes helm chart.
Prerequisites
Complete the following prerequisites prior to implementing the integration described in this topic:
- Verify that you have completed the steps described in Systems Integration section of Vault as a Secrets Backend.
- You should be familiar with the Data Integration Overview section of Vault as a Secrets Backend.
- Configure Vault as the Server TLS Certificate Provider on Kubernetes
- Configure Vault as the Service Mesh Certificate Provider on Kubernetes
Bootstrapping the PKI Engines
Issue the following commands to enable and configure the PKI Secrets Engine to serve TLS certificates for the controller and connect inject webhooks:
Mount the PKI Secrets Engine for each:
Tune the engine mounts to enable longer TTL:
Generate the root CA for each:
Create Vault Policies
Create a policy that allows
["create", "update"]
access to the certificate issuing URL so Consul controller and connect inject can fetch a new certificate/key pair and provide it to the Kubernetesmutatingwebhookconfiguration
.The path to the secret referenced in the
path
resource is the same value that you will configure in theglobal.secretsBackend.vault.controller.tlsCert.secretName
andglobal.secretsBackend.vault.connectInject.tlsCert.secretName
Helm configuration (refer to Update Consul on Kubernetes Helm chart).Create a policy that allows
["read"]
access to the CA URL, this is required for the Consul components to communicate with the Consul servers in order to fetch their auto-encryption certificates.The path to the secret referenced in the
path
resource is the same values that you will configure in theglobal.secretsBackend.vault.controller.caCert.secretName
andglobal.secretsBackend.vault.connectInject.caCert.secretName
Helm configuration (refer to Update Consul on Kubernetes Helm chart).Configure allowed domains for PKI certificates.
To generate the
<Allowed-domains-string>
for each use the following script as a template:Finally, Kubernetes auth roles need to be created for controller and connect inject webhooks.
The path to the secret referenced in the
path
resource is the same values that you will configure in theglobal.secretsBackend.vault.controllerRole
andglobal.secretsBackend.vault.connectInjectRole
Helm configuration (refer to Update Consul on Kubernetes Helm chart).Role for Consul controller webhooks:
To find out the service account name of the Consul controller, you can run:
Role for Consul connect inject webhooks:
To find out the service account name of the Consul connect inject, use the command below.
Update Consul on Kubernetes Helm chart
Now that we've configured Vault, you can configure the Consul Helm chart to use the Server TLS certificates from Vault:
The vaultCASecret
is the Kubernetes secret that stores the CA Certificate that is used for Vault communication. To provide a CA, you first need to create a Kubernetes secret containing the CA. For example, you may create a secret with the Vault CA like so: