Merge branch 'main' of github.com:hashicorp/consul into docs-ecs-mesh-gw
This commit is contained in:
trujillo-adam
commit
461dbb2e77
|
|
@ -9,8 +9,8 @@ description: >-
|
|||
|
||||
## Overview
|
||||
|
||||
Consul on Kubernetes provides a few options for customizing how connect-inject behavior should be configured.
|
||||
This allows the user to configure natively configure Consul on select Kubernetes resources (i.e. pods, services).
|
||||
Consul on Kubernetes provides a few options for customizing how connect-inject behavior should be configured.
|
||||
This allows the user to configure natively configure Consul on select Kubernetes resources (i.e. pods, services).
|
||||
|
||||
- [Annotations](#annotations)
|
||||
- [Labels](#labels)
|
||||
|
|
@ -155,7 +155,7 @@ Resource annotations could be used on the Kubernetes pod to control connect-inje
|
|||
consul.hashicorp.com/service-meta-foo: baz
|
||||
consul.hashicorp.com/service-meta-bar: baz
|
||||
```
|
||||
|
||||
|
||||
- `consul.hashicorp.com/sidecar-proxy-` - Override default resource settings for
|
||||
the sidecar proxy container.
|
||||
The defaults are set in Helm config via the [`connectInject.sidecarProxy.resources`](/docs/k8s/helm#v-connectinject-sidecarproxy-resources) key.
|
||||
|
|
@ -165,6 +165,9 @@ Resource annotations could be used on the Kubernetes pod to control connect-inje
|
|||
- `consul.hashicorp.com/sidecar-proxy-memory-limit` - Override the default memory limit.
|
||||
- `consul.hashicorp.com/sidecar-proxy-memory-request` - Override the default memory request.
|
||||
|
||||
- `consul.hashicorp.com/consul-envoy-proxy-concurrency` - Override the default envoy worker thread count. This should be set low for sidecar
|
||||
usecases and can be raised for edge proxies like gateways.
|
||||
|
||||
- `consul.hashicorp.com/consul-sidecar-` - Override default resource settings for
|
||||
the `consul-sidecar` container.
|
||||
The defaults are set in Helm config via the [`global.consulSidecarContainer.resources`](/docs/k8s/helm#v-global-consulsidecarcontainer) key.
|
||||
|
|
@ -185,7 +188,7 @@ Resource annotations could be used on the Kubernetes pod to control connect-inje
|
|||
|
||||
## Labels
|
||||
|
||||
Resource labels could be used on a Kubernetes service to control connect-inject behavior.
|
||||
Resource labels could be used on a Kubernetes service to control connect-inject behavior.
|
||||
|
||||
- `consul.hashicorp.com/service-ignore` - This label can be set on a Kubernetes Service.
|
||||
If set to "true", the service will not be used to register a Consul endpoint. This can be
|
||||
|
|
|
|||
|
|
@ -58,7 +58,7 @@ Use these links to navigate to a particular top-level stanza.
|
|||
the prefix will be `<helm release name>-consul`.
|
||||
|
||||
- `domain` ((#v-global-domain)) (`string: consul`) - The domain Consul will answer DNS queries for
|
||||
(see `-domain` (https://consul.io/docs/agent/config/cli-flags#_domain)) and the domain services synced from
|
||||
(see `-domain` (https://www.consul.io/docs/agent/config/cli-flags#_domain)) and the domain services synced from
|
||||
Consul into Kubernetes will have, e.g. `service-name.service.consul`.
|
||||
|
||||
- `adminPartitions` ((#v-global-adminpartitions)) - <EnterpriseAlert inline /> Enabling `adminPartitions` allows creation of Admin Partitions in Kubernetes clusters.
|
||||
|
|
@ -203,6 +203,21 @@ Use these links to navigate to a particular top-level stanza.
|
|||
```
|
||||
and check the name of `metadata.name`.
|
||||
|
||||
- `controllerRole` ((#v-global-secretsbackend-vault-controllerrole)) (`string: ""`) - The Vault role to read Consul controller's webhook's
|
||||
CA and issue a certificate and private key.
|
||||
A Vault policy must be created which grants issue capabilities to
|
||||
`global.secretsBackend.vault.controller.tlsCert.secretName`.
|
||||
|
||||
- `connectInjectRole` ((#v-global-secretsbackend-vault-connectinjectrole)) (`string: ""`) - The Vault role to read Consul connect-injector webhook's CA
|
||||
and issue a certificate and private key.
|
||||
A Vault policy must be created which grants issue capabilities to
|
||||
`global.secretsBackend.vault.connectInject.tlsCert.secretName`.
|
||||
|
||||
- `consulCARole` ((#v-global-secretsbackend-vault-consulcarole)) (`string: ""`) - The Vault role for all Consul components to read the Consul's server's CA Certificate (unauthenticated).
|
||||
The role should be connected to the service accounts of all Consul components, or alternatively `*` since it
|
||||
will be used only against the `pki/cert/ca` endpoint which is unauthenticated. A policy must be created which grants
|
||||
read capabilities to `global.tls.caCert.secretName`, which is usually `pki/cert/ca`.
|
||||
|
||||
- `agentAnnotations` ((#v-global-secretsbackend-vault-agentannotations)) (`string: null`) - This value defines additional annotations for
|
||||
Vault agent on any pods where it'll be running.
|
||||
This should be formatted as a multi-line string.
|
||||
|
|
@ -213,11 +228,6 @@ Use these links to navigate to a particular top-level stanza.
|
|||
"sample/annotation2": "bar"
|
||||
```
|
||||
|
||||
- `consulCARole` ((#v-global-secretsbackend-vault-consulcarole)) (`string: ""`) - The Vault role for all Consul components to read the Consul's server's CA Certificate (unauthenticated).
|
||||
The role should be connected to the service accounts of all Consul components, or alternatively `*` since it
|
||||
will be used only against the `pki/cert/ca` endpoint which is unauthenticated. A policy must be created which grants
|
||||
read capabilities to `global.tls.caCert.secretName`, which is usually `pki/cert/ca`.
|
||||
|
||||
- `ca` ((#v-global-secretsbackend-vault-ca)) - Configuration for Vault server CA certificate. This certificate will be mounted
|
||||
to any pod where Vault agent needs to run.
|
||||
|
||||
|
|
@ -260,8 +270,40 @@ Use these links to navigate to a particular top-level stanza.
|
|||
}
|
||||
```
|
||||
|
||||
- `controller` ((#v-global-secretsbackend-vault-controller))
|
||||
|
||||
- `tlsCert` ((#v-global-secretsbackend-vault-controller-tlscert)) - Configuration to the Vault Secret that Kubernetes will use on
|
||||
Kubernetes CRD creation, deletion, and update, to get TLS certificates
|
||||
used issued from vault to send webhooks to the controller.
|
||||
|
||||
- `secretName` ((#v-global-secretsbackend-vault-controller-tlscert-secretname)) (`string: null`) - The Vault secret path that issues TLS certificates for controller
|
||||
webhooks.
|
||||
|
||||
- `caCert` ((#v-global-secretsbackend-vault-controller-cacert)) - Configuration to the Vault Secret that Kubernetes will use on
|
||||
Kubernetes CRD creation, deletion, and update, to get CA certificates
|
||||
used issued from vault to send webhooks to the controller.
|
||||
|
||||
- `secretName` ((#v-global-secretsbackend-vault-controller-cacert-secretname)) (`string: null`) - The Vault secret path that contains the CA certificate for controller
|
||||
webhooks.
|
||||
|
||||
- `connectInject` ((#v-global-secretsbackend-vault-connectinject))
|
||||
|
||||
- `caCert` ((#v-global-secretsbackend-vault-connectinject-cacert)) - Configuration to the Vault Secret that Kubernetes will use on
|
||||
Kubernetes pod creation, deletion, and update, to get CA certificates
|
||||
used issued from vault to send webhooks to the ConnectInject.
|
||||
|
||||
- `secretName` ((#v-global-secretsbackend-vault-connectinject-cacert-secretname)) (`string: null`) - The Vault secret path that contains the CA certificate for
|
||||
Connect Inject webhooks.
|
||||
|
||||
- `tlsCert` ((#v-global-secretsbackend-vault-connectinject-tlscert)) - Configuration to the Vault Secret that Kubernetes will use on
|
||||
Kubernetes pod creation, deletion, and update, to get TLS certificates
|
||||
used issued from vault to send webhooks to the ConnectInject.
|
||||
|
||||
- `secretName` ((#v-global-secretsbackend-vault-connectinject-tlscert-secretname)) (`string: null`) - The Vault secret path that issues TLS certificates for connect
|
||||
inject webhooks.
|
||||
|
||||
- `gossipEncryption` ((#v-global-gossipencryption)) - Configures Consul's gossip encryption key.
|
||||
(see `-encrypt` (https://consul.io/docs/agent/config/cli-flags#_encrypt)).
|
||||
(see `-encrypt` (https://www.consul.io/docs/agent/config/cli-flags#_encrypt)).
|
||||
By default, gossip encryption is not enabled. The gossip encryption key may be set automatically or manually.
|
||||
The recommended method is to automatically generate the key.
|
||||
To automatically generate and set a gossip encryption key, set autoGenerate to true.
|
||||
|
|
@ -316,7 +358,7 @@ Use these links to navigate to a particular top-level stanza.
|
|||
Consul server(s) externally, for example, if you're using the UI.
|
||||
|
||||
- `verify` ((#v-global-tls-verify)) (`boolean: true`) - If true, `verify_outgoing`, `verify_server_hostname`,
|
||||
and `verify_incoming_rpc` will be set to `true` for Consul servers and clients.
|
||||
and `verify_incoming` for internal RPC communication will be set to `true` for Consul servers and clients.
|
||||
Set this to false to incrementally roll out TLS on an existing Consul cluster.
|
||||
Please see https://consul.io/docs/k8s/operations/tls-on-existing-cluster
|
||||
for more details.
|
||||
|
|
@ -448,10 +490,9 @@ Use these links to navigate to a particular top-level stanza.
|
|||
- `k8sAuthMethodHost` ((#v-global-federation-k8sauthmethodhost)) (`string: null`) - If you are setting `global.federation.enabled` to true and are in a secondary datacenter,
|
||||
set `k8sAuthMethodHost` to the address of the Kubernetes API server of the secondary datacenter.
|
||||
This address must be reachable from the Consul servers in the primary datacenter.
|
||||
|
||||
This auth method will be used to provision ACL tokens for Consul components and is different
|
||||
from the one used by the Consul Service Mesh.
|
||||
Please see the [Kubernetes Auth Method documentation](https://consul.io/docs/acl/auth-methods/kubernetes) for additional information.
|
||||
Please see the [Kubernetes Auth Method documentation](https://consul.io/docs/acl/auth-methods/kubernetes).
|
||||
|
||||
You can retrieve this value from your `kubeconfig` by running:
|
||||
|
||||
|
|
@ -500,6 +541,9 @@ Use these links to navigate to a particular top-level stanza.
|
|||
- `enabled` ((#v-global-openshift-enabled)) (`boolean: false`) - If true, the Helm chart will create necessary configuration for running
|
||||
its components on OpenShift.
|
||||
|
||||
- `consulAPITimeout` ((#v-global-consulapitimeout)) (`string: 5s`) - The time in seconds that the consul API client will wait for a response from
|
||||
the API before cancelling the request.
|
||||
|
||||
### server
|
||||
|
||||
- `server` ((#v-server)) - Server, when enabled, configures a server cluster to run. This should
|
||||
|
|
@ -663,7 +707,7 @@ Use these links to navigate to a particular top-level stanza.
|
|||
--set 'server.disruptionBudget.maxUnavailable=0'` flag to the helm chart installation
|
||||
command because of a limitation in the Helm templating language.
|
||||
|
||||
- `extraConfig` ((#v-server-extraconfig)) (`string: {}`) - A raw string of extra JSON configuration (https://consul.io/docs/agent/config) for Consul
|
||||
- `extraConfig` ((#v-server-extraconfig)) (`string: {}`) - A raw string of extra JSON configuration (https://consul.io/docs/agent/options) for Consul
|
||||
servers. This will be saved as-is into a ConfigMap that is read by the Consul
|
||||
server agents. This can be used to add additional configuration that
|
||||
isn't directly exposed by the chart.
|
||||
|
|
@ -864,7 +908,7 @@ Use these links to navigate to a particular top-level stanza.
|
|||
- `image` ((#v-client-image)) (`string: null`) - The name of the Docker image (including any tag) for the containers
|
||||
running Consul client agents.
|
||||
|
||||
- `join` ((#v-client-join)) (`array<string>: null`) - A list of valid `-retry-join` values (https://consul.io/docs/agent/config/config-files#retry-join).
|
||||
- `join` ((#v-client-join)) (`array<string>: null`) - A list of valid `-retry-join` values (https://www.consul.io/docs/agent/config/cli-flags#_retry_join).
|
||||
If this is `null` (default), then the clients will attempt to automatically
|
||||
join the server cluster running within Kubernetes.
|
||||
This means that with `server.enabled` set to true, clients will automatically
|
||||
|
|
@ -929,7 +973,7 @@ Use these links to navigate to a particular top-level stanza.
|
|||
|
||||
- `tlsInit` ((#v-client-containersecuritycontext-tlsinit)) (`map`) - The tls-init initContainer
|
||||
|
||||
- `extraConfig` ((#v-client-extraconfig)) (`string: {}`) - A raw string of extra JSON configuration (https://consul.io/docs/agent/config) for Consul
|
||||
- `extraConfig` ((#v-client-extraconfig)) (`string: {}`) - A raw string of extra JSON configuration (https://consul.io/docs/agent/options) for Consul
|
||||
clients. This will be saved as-is into a ConfigMap that is read by the Consul
|
||||
client agents. This can be used to add additional configuration that
|
||||
isn't directly exposed by the chart.
|
||||
|
|
@ -1080,6 +1124,9 @@ Use these links to navigate to a particular top-level stanza.
|
|||
|
||||
- `replicas` ((#v-client-snapshotagent-replicas)) (`integer: 2`) - The number of snapshot agents to run.
|
||||
|
||||
- `interval` ((#v-client-snapshotagent-interval)) (`string: 1h`) - Interval at which to perform snapshots.
|
||||
See https://www.consul.io/commands/snapshot/agent#interval
|
||||
|
||||
- `configSecret` ((#v-client-snapshotagent-configsecret)) - A Kubernetes or Vault secret that should be manually created to contain the entire
|
||||
config to be used on the snapshot agent.
|
||||
This is the preferred method of configuration since there are usually storage
|
||||
|
|
@ -1238,7 +1285,7 @@ Use these links to navigate to a particular top-level stanza.
|
|||
will inherit from `global.metrics.enabled` value.
|
||||
|
||||
- `provider` ((#v-ui-metrics-provider)) (`string: prometheus`) - Provider for metrics. See
|
||||
https://www.consul.io/docs/agent/config/config-files#ui_config_metrics_provider
|
||||
https://www.consul.io/docs/agent/options#ui_config_metrics_provider
|
||||
This value is only used if `ui.enabled` is set to true.
|
||||
|
||||
- `baseURL` ((#v-ui-metrics-baseurl)) (`string: http://prometheus-server`) - baseURL is the URL of the prometheus server, usually the service URL.
|
||||
|
|
@ -1324,6 +1371,9 @@ Use these links to navigate to a particular top-level stanza.
|
|||
already exist, it will be created. Turning this on overrides the
|
||||
`consulDestinationNamespace` setting.
|
||||
`addK8SNamespaceSuffix` may no longer be needed if enabling this option.
|
||||
If mirroring is enabled, avoid creating any Consul resources in the following
|
||||
Kubernetes namespaces, as Consul currently reserves these namespaces for
|
||||
system use: "system", "universal", "operator", "root".
|
||||
|
||||
- `mirroringK8SPrefix` ((#v-synccatalog-consulnamespaces-mirroringk8sprefix)) (`string: ""`) - If `mirroringK8S` is set to true, `mirroringK8SPrefix` allows each Consul namespace
|
||||
to be given a prefix. For example, if `mirroringK8SPrefix` is set to "k8s-", a
|
||||
|
|
@ -1576,7 +1626,9 @@ Use these links to navigate to a particular top-level stanza.
|
|||
of the same name as their k8s namespace, optionally prefixed if
|
||||
`mirroringK8SPrefix` is set below. If the Consul namespace does not
|
||||
already exist, it will be created. Turning this on overrides the
|
||||
`consulDestinationNamespace` setting.
|
||||
`consulDestinationNamespace` setting. If mirroring is enabled, avoid creating any Consul
|
||||
resources in the following Kubernetes namespaces, as Consul currently reserves these
|
||||
namespaces for system use: "system", "universal", "operator", "root".
|
||||
|
||||
- `mirroringK8SPrefix` ((#v-connectinject-consulnamespaces-mirroringk8sprefix)) (`string: ""`) - If `mirroringK8S` is set to true, `mirroringK8SPrefix` allows each Consul namespace
|
||||
to be given a prefix. For example, if `mirroringK8SPrefix` is set to "k8s-", a
|
||||
|
|
@ -1629,6 +1681,16 @@ Use these links to navigate to a particular top-level stanza.
|
|||
|
||||
- `sidecarProxy` ((#v-connectinject-sidecarproxy))
|
||||
|
||||
- `concurrency` ((#v-connectinject-sidecarproxy-concurrency)) (`string: 2`) - The number of worker threads to be used by the Envoy proxy.
|
||||
By default the threading model of Envoy will use one thread per CPU core per envoy proxy. This
|
||||
leads to unnecessary thread and memory usage and leaves unnecessary idle connections open. It is
|
||||
advised to keep this number low for sidecars and high for edge proxies.
|
||||
This will control the `--concurrency` flag to Envoy.
|
||||
For additional information see also: https://blog.envoyproxy.io/envoy-threading-model-a8d44b922310
|
||||
|
||||
This setting can be overridden on a per-pod basis via this annotation:
|
||||
- `consul.hashicorp.com/consul-envoy-proxy-concurrency`
|
||||
|
||||
- `resources` ((#v-connectinject-sidecarproxy-resources)) (`map`) - Set default resources for sidecar proxy. If null, that resource won't
|
||||
be set.
|
||||
These settings can be overridden on a per-pod basis via these annotations:
|
||||
|
|
@ -1821,6 +1883,26 @@ Use these links to navigate to a particular top-level stanza.
|
|||
|
||||
- `tolerations` ((#v-meshgateway-tolerations)) (`string: null`) - Optional YAML string to specify tolerations.
|
||||
|
||||
- `topologySpreadConstraints` ((#v-meshgateway-topologyspreadconstraints)) (`string: ""`) - Pod topology spread constraints for mesh gateway pods.
|
||||
This should be a multi-line YAML string matching the `topologySpreadConstraints` array
|
||||
(https://kubernetes.io/docs/concepts/workloads/pods/pod-topology-spread-constraints/) in a Pod Spec.
|
||||
|
||||
This requires K8S >= 1.18 (beta) or 1.19 (stable).
|
||||
|
||||
Example:
|
||||
|
||||
```yaml
|
||||
topologySpreadConstraints: |
|
||||
- maxSkew: 1
|
||||
topologyKey: topology.kubernetes.io/zone
|
||||
whenUnsatisfiable: DoNotSchedule
|
||||
labelSelector:
|
||||
matchLabels:
|
||||
app: {{ template "consul.name" . }}
|
||||
release: "{{ .Release.Name }}"
|
||||
component: mesh-gateway
|
||||
```
|
||||
|
||||
- `nodeSelector` ((#v-meshgateway-nodeselector)) (`string: null`) - Optional YAML string to specify a nodeSelector config.
|
||||
|
||||
- `priorityClassName` ((#v-meshgateway-priorityclassname)) (`string: ""`) - Optional priorityClassName.
|
||||
|
|
@ -1901,6 +1983,26 @@ Use these links to navigate to a particular top-level stanza.
|
|||
|
||||
- `tolerations` ((#v-ingressgateways-defaults-tolerations)) (`string: null`) - Optional YAML string to specify tolerations.
|
||||
|
||||
- `topologySpreadConstraints` ((#v-ingressgateways-defaults-topologyspreadconstraints)) (`string: ""`) - Pod topology spread constraints for ingress gateway pods.
|
||||
This should be a multi-line YAML string matching the `topologySpreadConstraints` array
|
||||
(https://kubernetes.io/docs/concepts/workloads/pods/pod-topology-spread-constraints/) in a Pod Spec.
|
||||
|
||||
This requires K8S >= 1.18 (beta) or 1.19 (stable).
|
||||
|
||||
Example:
|
||||
|
||||
```yaml
|
||||
topologySpreadConstraints: |
|
||||
- maxSkew: 1
|
||||
topologyKey: topology.kubernetes.io/zone
|
||||
whenUnsatisfiable: DoNotSchedule
|
||||
labelSelector:
|
||||
matchLabels:
|
||||
app: {{ template "consul.name" . }}
|
||||
release: "{{ .Release.Name }}"
|
||||
component: ingress-gateway
|
||||
```
|
||||
|
||||
- `nodeSelector` ((#v-ingressgateways-defaults-nodeselector)) (`string: null`) - Optional YAML string to specify a nodeSelector config.
|
||||
|
||||
- `priorityClassName` ((#v-ingressgateways-defaults-priorityclassname)) (`string: ""`) - Optional priorityClassName.
|
||||
|
|
@ -1974,6 +2076,26 @@ Use these links to navigate to a particular top-level stanza.
|
|||
|
||||
- `tolerations` ((#v-terminatinggateways-defaults-tolerations)) (`string: null`) - Optional YAML string to specify tolerations.
|
||||
|
||||
- `topologySpreadConstraints` ((#v-terminatinggateways-defaults-topologyspreadconstraints)) (`string: ""`) - Pod topology spread constraints for terminating gateway pods.
|
||||
This should be a multi-line YAML string matching the `topologySpreadConstraints` array
|
||||
(https://kubernetes.io/docs/concepts/workloads/pods/pod-topology-spread-constraints/) in a Pod Spec.
|
||||
|
||||
This requires K8S >= 1.18 (beta) or 1.19 (stable).
|
||||
|
||||
Example:
|
||||
|
||||
```yaml
|
||||
topologySpreadConstraints: |
|
||||
- maxSkew: 1
|
||||
topologyKey: topology.kubernetes.io/zone
|
||||
whenUnsatisfiable: DoNotSchedule
|
||||
labelSelector:
|
||||
matchLabels:
|
||||
app: {{ template "consul.name" . }}
|
||||
release: "{{ .Release.Name }}"
|
||||
component: terminating-gateway
|
||||
```
|
||||
|
||||
- `nodeSelector` ((#v-terminatinggateways-defaults-nodeselector)) (`string: null`) - Optional YAML string to specify a nodeSelector config.
|
||||
|
||||
- `priorityClassName` ((#v-terminatinggateways-defaults-priorityclassname)) (`string: ""`) - Optional priorityClassName.
|
||||
|
|
@ -2051,25 +2173,16 @@ Use these links to navigate to a particular top-level stanza.
|
|||
- external-dns.alpha.kubernetes.io/hostname
|
||||
```
|
||||
|
||||
- `consulNamespaces` ((#v-apigateway-consulnamespaces)) - <EnterpriseAlert inline /> These settings manage the API Gateway's interaction with
|
||||
Consul namespaces (requires consul-ent v1.7+).
|
||||
Also, `global.enableConsulNamespaces` must be true.
|
||||
- `deployment` ((#v-apigateway-managedgatewayclass-deployment)) (`map`) - This value defines the number of pods to deploy for each Gateway as well as a min and max number of pods for all Gateways
|
||||
|
||||
- `consulDestinationNamespace` ((#v-apigateway-consulnamespaces-consuldestinationnamespace)) (`string: default`) - Name of the Consul namespace to register all
|
||||
k8s services into. If the Consul namespace does not already exist,
|
||||
it will be created. This will be ignored if `mirroringK8S` is true.
|
||||
Example:
|
||||
|
||||
- `mirroringK8S` ((#v-apigateway-consulnamespaces-mirroringk8s)) (`boolean: false`) - If true, k8s services will be registered into a Consul namespace
|
||||
of the same name as their k8s namespace, optionally prefixed if
|
||||
`mirroringK8SPrefix` is set below. If the Consul namespace does not
|
||||
already exist, it will be created. Turning this on overrides the
|
||||
`consulDestinationNamespace` setting.
|
||||
`addK8SNamespaceSuffix` may no longer be needed if enabling this option.
|
||||
|
||||
- `mirroringK8SPrefix` ((#v-apigateway-consulnamespaces-mirroringk8sprefix)) (`string: ""`) - If `mirroringK8S` is set to true, `mirroringK8SPrefix` allows each Consul namespace
|
||||
to be given a prefix. For example, if `mirroringK8SPrefix` is set to "k8s-", a
|
||||
service in the k8s `staging` namespace will be registered into the
|
||||
`k8s-staging` Consul namespace.
|
||||
```yaml
|
||||
deployment:
|
||||
defaultInstances: 3
|
||||
maxInstances: 8
|
||||
minInstances: 1
|
||||
```
|
||||
|
||||
- `serviceAccount` ((#v-apigateway-serviceaccount)) - Configuration for the ServiceAccount created for the api-gateway component
|
||||
|
||||
|
|
|
|||
|
|
@ -7,11 +7,7 @@ description: >-
|
|||
|
||||
# Storing the ACL Bootstrap Token in Vault
|
||||
|
||||
## Prerequisites
|
||||
Prior to setting up the data integration between Vault and Consul on Kubernetes, you will need to have:
|
||||
1. Read and completed the steps in the [Systems Integration](/docs/k8s/installation/vault/systems-integration) section of [Vault as a Secrets Backend](/docs/k8s/installation/vault).
|
||||
2. Read the [Data Integration Overview](/docs/k8s/installation/vault/data-integration) section of [Vault as a Secrets Backend](/docs/k8s/installation/vault).
|
||||
|
||||
This topic describes how to configure the Consul Helm chart to use an ACL bootstrap token stored in Vault.
|
||||
## Overview
|
||||
To use an ACL bootstrap token stored in Vault, we will follow the steps outlined in the [Data Integration](/docs/k8s/installation/vault/data-integration) section:
|
||||
|
||||
|
|
@ -22,8 +18,12 @@ To use an ACL bootstrap token stored in Vault, we will follow the steps outlined
|
|||
|
||||
### Setup per Consul datacenter
|
||||
1. Create Vault Kubernetes auth roles that link the policy to each Consul on Kubernetes service account that requires access.
|
||||
1. Configure the Vault Kubernetes auth role in the Consul on Kubernetes helm chart.
|
||||
1. Update the Consul on Kubernetes helm chart.
|
||||
|
||||
## Prerequisites
|
||||
Prior to setting up the data integration between Vault and Consul on Kubernetes, you will need to have:
|
||||
1. Read and completed the steps in the [Systems Integration](/docs/k8s/installation/vault/systems-integration) section of [Vault as a Secrets Backend](/docs/k8s/installation/vault).
|
||||
2. Read the [Data Integration Overview](/docs/k8s/installation/vault/data-integration) section of [Vault as a Secrets Backend](/docs/k8s/installation/vault).
|
||||
## One time setup in Vault
|
||||
### Generate and Store the Secret in Vault
|
||||
|
||||
|
|
@ -75,7 +75,7 @@ you can run the following `helm template` command with your Consul on Kubernetes
|
|||
$ helm template --release-name ${RELEASE_NAME} -s templates/server-acl-init-serviceaccount.yaml hashicorp/consul
|
||||
```
|
||||
|
||||
### Configure the Vault Kubernetes auth role in the Consul on Kubernetes helm chart
|
||||
### Update the Consul on Kubernetes helm chart
|
||||
|
||||
Now that you have configured Vault, you can configure the Consul Helm chart to
|
||||
use the ACL bootstrap token in Vault:
|
||||
|
|
|
|||
|
|
@ -7,17 +7,12 @@ description: >-
|
|||
|
||||
# Vault as the Service Mesh Certificate Provider on Kubernetes
|
||||
|
||||
This topic describes how to configure the Consul Helm chart to use TLS certificates issued by Vault for Consul service mesh communication.
|
||||
|
||||
-> **Note:** This feature requires Consul 1.11 or higher. As of v1.11,
|
||||
Consul allows using Kubernetes auth methods to configure Connect CA.
|
||||
This allows for automatic token rotation once the renewal is no longer possible.
|
||||
|
||||
|
||||
## Prerequisites
|
||||
Prior to setting up the data integration between Vault and Consul on Kubernetes, you will need to have:
|
||||
1. Read and completed the steps in the [Systems Integration](/docs/k8s/installation/vault/systems-integration) section of [Vault as a Secrets Backend](/docs/k8s/installation/vault).
|
||||
2. Read the [Data Integration Overview](/docs/k8s/installation/vault/data-integration) section of [Vault as a Secrets Backend](/docs/k8s/installation/vault).
|
||||
|
||||
|
||||
## Overview
|
||||
To use an Vault as the Service Mesh Certificate Provider on Kubernetes, we will need to modify the steps outlined in the [Data Integration](/docs/k8s/installation/vault/data-integration) section:
|
||||
|
||||
|
|
@ -26,7 +21,12 @@ To use an Vault as the Service Mesh Certificate Provider on Kubernetes, we will
|
|||
|
||||
### Setup per Consul datacenter
|
||||
1. Create Vault Kubernetes auth roles that link the policy to each Consul on Kubernetes service account that requires access.
|
||||
1. Configure the Vault Kubernetes auth role in the Consul on Kubernetes helm chart.
|
||||
1. Update the Consul on Kubernetes helm chart.
|
||||
|
||||
## Prerequisites
|
||||
Prior to setting up the data integration between Vault and Consul on Kubernetes, you will need to have:
|
||||
1. Read and completed the steps in the [Systems Integration](/docs/k8s/installation/vault/systems-integration) section of [Vault as a Secrets Backend](/docs/k8s/installation/vault).
|
||||
2. Read the [Data Integration Overview](/docs/k8s/installation/vault/data-integration) section of [Vault as a Secrets Backend](/docs/k8s/installation/vault).
|
||||
|
||||
## One time setup in Vault
|
||||
### Store the secret in Vault
|
||||
|
|
@ -60,7 +60,7 @@ you can run:
|
|||
$ helm template --release-name ${RELEASE_NAME} --show-only templates/server-serviceaccount.yaml hashicorp/consul
|
||||
```
|
||||
|
||||
### Configure the Vault Kubernetes auth role in the Consul on Kubernetes helm chart
|
||||
### Update the Consul on Kubernetes helm chart
|
||||
Now you can configure the Consul Helm chart to use Vault as the Connect CA provider:
|
||||
|
||||
<CodeBlockConfig filename="values.yaml">
|
||||
|
|
|
|||
|
|
@ -7,11 +7,7 @@ description: >-
|
|||
|
||||
# Storing the Enterprise License in Vault
|
||||
|
||||
## Prerequisites
|
||||
Prior to setting up the data integration between Vault and Consul on Kubernetes, you will need to have:
|
||||
1. Read and completed the steps in the [Systems Integration](/docs/k8s/installation/vault/systems-integration) section of [Vault as a Secrets Backend](/docs/k8s/installation/vault).
|
||||
2. Read the [Data Integration Overview](/docs/k8s/installation/vault/data-integration) section of [Vault as a Secrets Backend](/docs/k8s/installation/vault).
|
||||
|
||||
This topic describes how to configure the Consul Helm chart to use an enterprise license stored in Vault.
|
||||
## Overview
|
||||
To use an enterprise license stored in Vault, we will follow the steps outlined in the [Data Integration](/docs/k8s/installation/vault/data-integration) section:
|
||||
|
||||
|
|
@ -21,7 +17,12 @@ To use an enterprise license stored in Vault, we will follow the steps outlined
|
|||
|
||||
### Setup per Consul datacenter
|
||||
1. Create Vault Kubernetes auth roles that link the policy to each Consul on Kubernetes service account that requires access.
|
||||
1. Configure the Vault Kubernetes auth role in the Consul on Kubernetes helm chart.
|
||||
1. Update the Consul on Kubernetes helm chart.
|
||||
|
||||
## Prerequisites
|
||||
Prior to setting up the data integration between Vault and Consul on Kubernetes, you will need to have:
|
||||
1. Read and completed the steps in the [Systems Integration](/docs/k8s/installation/vault/systems-integration) section of [Vault as a Secrets Backend](/docs/k8s/installation/vault).
|
||||
2. Read the [Data Integration Overview](/docs/k8s/installation/vault/data-integration) section of [Vault as a Secrets Backend](/docs/k8s/installation/vault).
|
||||
|
||||
## One time setup in Vault
|
||||
### Store the Secret in Vault
|
||||
|
|
@ -88,7 +89,7 @@ you can run the following `helm template` commands with your Consul on Kubernete
|
|||
$ helm template --release-name ${RELEASE_NAME} -s templates/client-serviceaccount.yaml hashicorp/consul
|
||||
```
|
||||
|
||||
### Configure the Vault Kubernetes auth role in the Consul on Kubernetes helm chart.
|
||||
### Update the Consul on Kubernetes helm chart.
|
||||
|
||||
Now that you have configured Vault, you can configure the Consul Helm chart to
|
||||
use the enterprise enterprise license in Vault:
|
||||
|
|
|
|||
|
|
@ -7,11 +7,6 @@ description: >-
|
|||
|
||||
# Storing Gossip Encryption Key in Vault
|
||||
|
||||
## Prerequisites
|
||||
Prior to setting up the data integration between Vault and Consul on Kubernetes, you will need to have:
|
||||
1. Read and completed the steps in the [Systems Integration](/docs/k8s/installation/vault/systems-integration) section of [Vault as a Secrets Backend](/docs/k8s/installation/vault).
|
||||
2. Read the [Data Integration Overview](/docs/k8s/installation/vault/data-integration) section of [Vault as a Secrets Backend](/docs/k8s/installation/vault).
|
||||
|
||||
## Overview
|
||||
To use a gossip encryption key stored in Vault, we will follow the steps outlined in the [Data Integration](/docs/k8s/installation/vault/data-integration) section:
|
||||
|
||||
|
|
@ -21,7 +16,12 @@ To use a gossip encryption key stored in Vault, we will follow the steps outline
|
|||
|
||||
### Setup per Consul datacenter
|
||||
1. Create Vault Kubernetes auth roles that link the policy to each Consul on Kubernetes service account that requires access.
|
||||
1. Configure the Vault Kubernetes auth role in the Consul on Kubernetes helm chart.
|
||||
1. Update the Consul on Kubernetes helm chart.
|
||||
|
||||
## Prerequisites
|
||||
Prior to setting up the data integration between Vault and Consul on Kubernetes, you will need to have:
|
||||
1. Read and completed the steps in the [Systems Integration](/docs/k8s/installation/vault/systems-integration) section of [Vault as a Secrets Backend](/docs/k8s/installation/vault).
|
||||
2. Read the [Data Integration Overview](/docs/k8s/installation/vault/data-integration) section of [Vault as a Secrets Backend](/docs/k8s/installation/vault).
|
||||
|
||||
## One time setup in Vault
|
||||
### Store the Secret in Vault
|
||||
|
|
@ -86,7 +86,7 @@ you can run the following `helm template` commands with your Consul on Kubernete
|
|||
$ helm template --release-name ${RELEASE_NAME} -s templates/client-serviceaccount.yaml hashicorp/consul
|
||||
```
|
||||
|
||||
### Configure the Vault Kubernetes auth role in the Consul on Kubernetes helm chart
|
||||
### Update the Consul on Kubernetes helm chart
|
||||
|
||||
Now that we've configured Vault, you can configure the Consul Helm chart to
|
||||
use the gossip key in Vault:
|
||||
|
|
|
|||
|
|
@ -7,11 +7,10 @@ description: >-
|
|||
|
||||
# Vault as the Secrets Backend - Data Integration
|
||||
|
||||
## Prerequisites
|
||||
Prior to setting up the data integration between Vault and Consul on Kubernetes, you will need to have read and completed the steps in the [Systems Integration](/docs/k8s/installation/vault/systems-integration) section of [Vault as a Secrets Backend](/docs/k8s/installation/vault).
|
||||
|
||||
## Overview
|
||||
|
||||
This topic describes an overview of how to configure Vault and Consul in order to share secrets for use within Consul.
|
||||
|
||||
### General Integration Steps
|
||||
|
||||
Generally, for each secret you wish to store in Vault, the process to integrate the data between Vault and Consul on Kubernetes is:
|
||||
|
|
@ -22,7 +21,10 @@ Generally, for each secret you wish to store in Vault, the process to integrate
|
|||
|
||||
#### Setup per Consul datacenter
|
||||
1. Create Vault Kubernetes auth roles that link the policy to each Consul on Kubernetes service account that requires access.
|
||||
1. Configure the Vault Kubernetes auth role in the Consul on Kubernetes helm chart.
|
||||
1. Update the Consul on Kubernetes helm chart.
|
||||
|
||||
## Prerequisites
|
||||
Prior to setting up the data integration between Vault and Consul on Kubernetes, you will need to have read and completed the steps in the [Systems Integration](/docs/k8s/installation/vault/systems-integration) section of [Vault as a Secrets Backend](/docs/k8s/installation/vault).
|
||||
|
||||
### Example - Gossip Encryption Key Integration
|
||||
|
||||
|
|
@ -41,7 +43,7 @@ Following the general integration steps, a more detailed workflow for integratio
|
|||
- Both Consul servers and Consul clients need access to the gossip encryption key, so you create two Vault Kubernetes:
|
||||
- A role called `consul-server` that maps the Kubernetes namespace and service account name for your consul servers to the `gossip-policy` created in [step 2](#one-time-setup-in-vault) of One time setup in Vault.
|
||||
- A role called `consul-client` that maps the Kubernetes namespace and service account name for your consul clients to the `gossip-policy` created in [step 2](#one-time-setup-in-vault) of One time setup in Vault..
|
||||
1. Configure the Vault Kubernetes auth role in the Consul on Kubernetes helm chart.
|
||||
1. Update the Consul on Kubernetes helm chart.
|
||||
- Configure the Vault Kubernetes auth roles created for the gossip encryption key:
|
||||
- [`global.secretsBackend.vault.consulServerRole`](/docs/k8s/helm#v-global-secretsbackend-vault-consulserverrole) is set to the `consul-server` Vault Kubernetes auth role created previously.
|
||||
- [`global.secretsBackend.vault.consulClientRole`](/docs/k8s/helm#v-global-secretsbackend-vault-consulclientrole) is set to the `consul-client` Vault Kubernetes auth role created previously.
|
||||
|
|
@ -64,6 +66,7 @@ It includes things like terminating gateways, ingress gateways, etc.)
|
|||
|[Snapshot Agent config](/docs/k8s/installation/vault/data-integration/snapshot-agent-config) | Consul snapshot agent | [`global.secretsBackend.vault.consulSnapshotAgentRole`](/docs/k8s/helm#v-global-secretsbackend-vault-consulsnapshotagentrole)|
|
||||
|[Server TLS credentials](/docs/k8s/installation/vault/data-integration/server-tls) | Consul servers<br/>Consul clients<br/>Consul components | [`global.secretsBackend.vault.consulServerRole`](/docs/k8s/helm#v-global-secretsbackend-vault-consulserverrole)<br/>[`global.secretsBackend.vault.consulClientRole`](/docs/k8s/helm#v-global-secretsbackend-vault-consulclientrole)<br/>[`global.secretsBackend.vault.consulCARole`](/docs/k8s/helm#v-global-secretsbackend-vault-consulcarole)|
|
||||
|[Service Mesh and Consul client TLS credentials](/docs/k8s/installation/vault/data-integration/connect-ca) | Consul servers | [`global.secretsBackend.vault.consulServerRole`](/docs/k8s/helm#v-global-secretsbackend-vault-consulserverrole)|
|
||||
|[Webhook TLS certificates for controller and connect inject](/docs/k8s/installation/vault/data-integration/connect-ca) | Consul controllers<br/>Consul connect inject | [`global.secretsBackend.vault.controllerRole`](/docs/k8s/helm#v-global-secretsbackend-vault-controllerrole)<br />[`global.secretsBackend.vault.connectInjectRole`](/docs/k8s/helm#v-global-secretsbackend-vault-controllerrole)|
|
||||
|
||||
### Secondary Datacenters
|
||||
The mapping for secondary data centers is similar with the following differences:
|
||||
|
|
@ -80,7 +83,7 @@ The mapping for secondary data centers is similar with the following differences
|
|||
|[Snapshot Agent config](/docs/k8s/installation/vault/data-integration/snapshot-agent-config) | Consul snapshot agent | [`global.secretsBackend.vault.consulSnapshotAgentRole`](/docs/k8s/helm#v-global-secretsbackend-vault-consulsnapshotagentrole)|
|
||||
|[Server TLS credentials](/docs/k8s/installation/vault/data-integration/server-tls) | Consul servers<br/>Consul clients<br/>Consul components | [`global.secretsBackend.vault.consulServerRole`](/docs/k8s/helm#v-global-secretsbackend-vault-consulserverrole)<br/>[`global.secretsBackend.vault.consulClientRole`](/docs/k8s/helm#v-global-secretsbackend-vault-consulclientrole)<br/>[`global.secretsBackend.vault.consulCARole`](/docs/k8s/helm#v-global-secretsbackend-vault-consulcarole)|
|
||||
|[Service Mesh and Consul client TLS credentials](/docs/k8s/installation/vault/data-integration/connect-ca) | Consul servers | [`global.secretsBackend.vault.consulServerRole`](/docs/k8s/helm#v-global-secretsbackend-vault-consulserverrole)|
|
||||
|
||||
|[Webhook TLS certificates for controller and connect inject](/docs/k8s/installation/vault/data-integration/connect-ca) | Consul controllers<br/>Consul connect inject | [`global.secretsBackend.vault.controllerRole`](/docs/k8s/helm#v-global-secretsbackend-vault-controllerrole)<br />[`global.secretsBackend.vault.connectInjectRole`](/docs/k8s/helm#v-global-secretsbackend-vault-controllerrole)|
|
||||
### Combining policies within roles
|
||||
As you can see in the table above, depending upon your needs, a Consul on Kubernetes service account could have the need to request more than one secret. In these cases, you will want to create one role for the Consul on Kubernetes service account that is mapped to multiple policies, each of which allows it access to a given secret.
|
||||
|
||||
|
|
@ -155,6 +158,7 @@ The following secrets can be stored in Vault KV secrets engine, which is meant t
|
|||
The following TLS certificates and keys can generated and managed by Vault the Vault PKI Engine, which is meant to handle things like certificate expiration and rotation:
|
||||
- [Server TLS credentials](/docs/k8s/installation/vault/data-integration/server-tls)
|
||||
- [Service Mesh and Consul client TLS credentials](/docs/k8s/installation/vault/data-integration/connect-ca)
|
||||
- [Vault as the Webhook Certificate Provider for Consul Controller and Connect Inject on Kubernetes](/docs/k8s/installation/vault/data-integration/webhook-certs)
|
||||
|
||||
## Secrets to Service Account Mapping
|
||||
Read through the [detailed data integration guides](#detailed-data-integration-guides) that are pertinent to your environment.
|
||||
|
|
|
|||
|
|
@ -7,10 +7,7 @@ description: >-
|
|||
|
||||
# Storing the ACL Partition Token in Vault
|
||||
|
||||
## Prerequisites
|
||||
Prior to setting up the data integration between Vault and Consul on Kubernetes, you will need to have:
|
||||
1. Read and completed the steps in the [Systems Integration](/docs/k8s/installation/vault/systems-integration) section of [Vault as a Secrets Backend](/docs/k8s/installation/vault).
|
||||
2. Read the [Data Integration Overview](/docs/k8s/installation/vault/data-integration) section of [Vault as a Secrets Backend](/docs/k8s/installation/vault).
|
||||
This topic describes how to configure the Consul Helm chart to use an ACL partition token stored in Vault.
|
||||
|
||||
## Overview
|
||||
To use an ACL partition token stored in Vault, we will follow the steps outlined in the [Data Integration](/docs/k8s/installation/vault/data-integration) section:
|
||||
|
|
@ -21,7 +18,12 @@ To use an ACL partition token stored in Vault, we will follow the steps outlined
|
|||
|
||||
### Setup per Consul datacenter
|
||||
1. Create Vault Kubernetes auth roles that link the policy to each Consul on Kubernetes service account that requires access.
|
||||
1. Configure the Vault Kubernetes auth role in the Consul on Kubernetes helm chart.
|
||||
1. Update the Consul on Kubernetes helm chart.
|
||||
|
||||
## Prerequisites
|
||||
Prior to setting up the data integration between Vault and Consul on Kubernetes, you will need to have:
|
||||
1. Read and completed the steps in the [Systems Integration](/docs/k8s/installation/vault/systems-integration) section of [Vault as a Secrets Backend](/docs/k8s/installation/vault).
|
||||
2. Read the [Data Integration Overview](/docs/k8s/installation/vault/data-integration) section of [Vault as a Secrets Backend](/docs/k8s/installation/vault).
|
||||
|
||||
## One time setup in Vault
|
||||
### Generate and Store the Secret in Vault
|
||||
|
|
@ -74,7 +76,7 @@ you can run the following `helm template` command with your Consul on Kubernetes
|
|||
$ helm template --release-name ${RELEASE_NAME} -s templates/server-acl-init-serviceaccount.yaml hashicorp/consul
|
||||
```
|
||||
|
||||
### Configure the Vault Kubernetes auth role in the Consul on Kubernetes helm chart
|
||||
### Update the Consul on Kubernetes helm chart
|
||||
|
||||
Now that you have configured Vault, you can configure the Consul Helm chart to
|
||||
use the ACL partition token key in Vault:
|
||||
|
|
|
|||
|
|
@ -7,11 +7,7 @@ description: >-
|
|||
|
||||
# Storing the ACL Replication Token in Vault
|
||||
|
||||
## Prerequisites
|
||||
Prior to setting up the data integration between Vault and Consul on Kubernetes, you will need to have:
|
||||
1. Read and completed the steps in the [Systems Integration](/docs/k8s/installation/vault/systems-integration) section of [Vault as a Secrets Backend](/docs/k8s/installation/vault).
|
||||
2. Read the [Data Integration Overview](/docs/k8s/installation/vault/data-integration) section of [Vault as a Secrets Backend](/docs/k8s/installation/vault).
|
||||
|
||||
This topic describes how to configure the Consul Helm chart to use an ACL replication token stored in Vault.
|
||||
## Overview
|
||||
To use an ACL replication token stored in Vault, we will follow the steps outlined in the [Data Integration](/docs/k8s/installation/vault/data-integration) section:
|
||||
|
||||
|
|
@ -21,7 +17,12 @@ To use an ACL replication token stored in Vault, we will follow the steps outlin
|
|||
|
||||
### Setup per Consul datacenter
|
||||
1. Create Vault Kubernetes auth roles that link the policy to each Consul on Kubernetes service account that requires access.
|
||||
1. Configure the Vault Kubernetes auth role in the Consul on Kubernetes helm chart.
|
||||
1. Update the Consul on Kubernetes helm chart.
|
||||
|
||||
## Prerequisites
|
||||
Prior to setting up the data integration between Vault and Consul on Kubernetes, you will need to have:
|
||||
1. Read and completed the steps in the [Systems Integration](/docs/k8s/installation/vault/systems-integration) section of [Vault as a Secrets Backend](/docs/k8s/installation/vault).
|
||||
2. Read the [Data Integration Overview](/docs/k8s/installation/vault/data-integration) section of [Vault as a Secrets Backend](/docs/k8s/installation/vault).
|
||||
|
||||
## One time setup in Vault
|
||||
### Generate and Store the Secret in Vault
|
||||
|
|
@ -74,7 +75,7 @@ you can run the following `helm template` command with your Consul on Kubernetes
|
|||
$ helm template --release-name ${RELEASE_NAME} -s templates/server-acl-init-serviceaccount.yaml hashicorp/consul
|
||||
```
|
||||
|
||||
### Configure the Vault Kubernetes auth role in the Consul on Kubernetes helm chart
|
||||
### Update the Consul on Kubernetes helm chart
|
||||
|
||||
Now that you have configured Vault, you can configure the Consul Helm chart to
|
||||
use the ACL replication token key in Vault:
|
||||
|
|
|
|||
|
|
@ -6,6 +6,18 @@ description: >-
|
|||
---
|
||||
|
||||
# Vault as the Server TLS Certificate Provider on Kubernetes
|
||||
|
||||
## Overview
|
||||
To use an Vault as the Server TLS Certificate Provider on Kubernetes, we will need to modify the steps outlined in the [Data Integration](/docs/k8s/installation/vault/data-integration) section:
|
||||
|
||||
### One time setup in Vault
|
||||
1. Create a Vault policy that authorizes the desired level of access to the secret.
|
||||
|
||||
### Setup per Consul datacenter
|
||||
1. (Added) Configure allowed domains for PKI certificates
|
||||
1. Create Vault Kubernetes auth roles that link the policy to each Consul on Kubernetes service account that requires access.
|
||||
1. Update the Consul on Kubernetes helm chart.
|
||||
|
||||
## Prerequisites
|
||||
Prior to setting up the data integration between Vault and Consul on Kubernetes, you will need to have:
|
||||
1. Read and completed the steps in the [Systems Integration](/docs/k8s/installation/vault/systems-integration) section of [Vault as a Secrets Backend](/docs/k8s/installation/vault).
|
||||
|
|
@ -39,19 +51,6 @@ which also uses an intermediate signing authority.
|
|||
common_name="dc1.consul" \
|
||||
ttl=87600h
|
||||
```
|
||||
|
||||
|
||||
## Overview
|
||||
To use an Vault as the Server TLS Certificate Provider on Kubernetes, we will need to modify the steps outlined in the [Data Integration](/docs/k8s/installation/vault/data-integration) section:
|
||||
|
||||
### One time setup in Vault
|
||||
1. Create a Vault policy that authorizes the desired level of access to the secret.
|
||||
|
||||
### Setup per Consul datacenter
|
||||
1. (Added) Create a Vault PKI role that establishes the domains that it is allowed to issue certificates for
|
||||
1. Create Vault Kubernetes auth roles that link the policy to each Consul on Kubernetes service account that requires access.
|
||||
1. Configure the Vault Kubernetes auth role in the Consul on Kubernetes helm chart.
|
||||
|
||||
## One time setup in Vault
|
||||
### Store the secret in Vault
|
||||
|
||||
|
|
@ -109,7 +108,7 @@ $ vault policy write ca-policy ca-policy.hcl
|
|||
-> **Note:** The PKI secret path referenced by the above Policy will be your `global.tls.caCert.secretName` Helm value.
|
||||
|
||||
## Setup per Consul datacenter
|
||||
### Create a Vault PKI role that establishes the domains that it is allowed to issue certificates for
|
||||
### Configure allowed domains for PKI certificates
|
||||
|
||||
Next, a Vault role for the PKI engine will set the default certificate issuance parameters:
|
||||
|
||||
|
|
@ -138,8 +137,8 @@ export DATACENTER=dc1
|
|||
echo allowed_domains=\"$DATACENTER.consul, $NAME-server, $NAME-server.$NAMESPACE, $NAME-server.$NAMESPACE.svc\"
|
||||
```
|
||||
|
||||
### Create a Vault auth roles that link the policy to each Consul on Kubernetes service account that requires access
|
||||
Finally, three Kubernetes auth roles need to be created, one for the Consul servers, one for the Consul clients, and one for Consul components.
|
||||
### Link the Vault policies to Consul workloads
|
||||
Create three Vault auth roles, one for the Consul servers, one for the Consul clients, and one for Consul components, that link the policy to each Consul workload on Kubernetes service account that requires access.
|
||||
|
||||
Role for Consul servers:
|
||||
```shell-session
|
||||
|
|
@ -184,7 +183,7 @@ $ vault write auth/kubernetes/role/consul-ca \
|
|||
The above Vault Roles will now be your Helm values for `global.secretsBackend.vault.consulServerRole` and
|
||||
`global.secretsBackend.vault.consulCARole` respectively.
|
||||
|
||||
### Configure the Vault Kubernetes auth role in the Consul on Kubernetes helm chart
|
||||
### Update the 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:
|
||||
|
|
|
|||
|
|
@ -7,11 +7,7 @@ description: >-
|
|||
|
||||
# Storing the Snapshot Agent Config in Vault
|
||||
|
||||
## Prerequisites
|
||||
Prior to setting up the data integration between Vault and Consul on Kubernetes, you will need to have:
|
||||
1. Read and completed the steps in the [Systems Integration](/docs/k8s/installation/vault/systems-integration) section of [Vault as a Secrets Backend](/docs/k8s/installation/vault).
|
||||
2. Read the [Data Integration Overview](/docs/k8s/installation/vault/data-integration) section of [Vault as a Secrets Backend](/docs/k8s/installation/vault).
|
||||
|
||||
This topic describes how to configure the Consul Helm chart to use a snapshot agent config stored in Vault.
|
||||
## Overview
|
||||
To use an ACL replication token stored in Vault, we will follow the steps outlined in the [Data Integration](/docs/k8s/installation/vault/data-integration) section:
|
||||
|
||||
|
|
@ -23,7 +19,12 @@ To use an ACL replication token stored in Vault, we will follow the steps outlin
|
|||
### Setup per Consul datacenter
|
||||
|
||||
1. Create Vault Kubernetes auth roles that link the policy to each Consul on Kubernetes service account that requires access.
|
||||
1. Configure the Vault Kubernetes auth role in the Consul on Kubernetes helm chart.
|
||||
1. Update the Consul on Kubernetes helm chart.
|
||||
|
||||
## Prerequisites
|
||||
Prior to setting up the data integration between Vault and Consul on Kubernetes, you will need to have:
|
||||
1. Read and completed the steps in the [Systems Integration](/docs/k8s/installation/vault/systems-integration) section of [Vault as a Secrets Backend](/docs/k8s/installation/vault).
|
||||
2. Read the [Data Integration Overview](/docs/k8s/installation/vault/data-integration) section of [Vault as a Secrets Backend](/docs/k8s/installation/vault).
|
||||
|
||||
## One time setup in Vault
|
||||
### Store the Secret in Vault
|
||||
|
|
@ -76,7 +77,7 @@ you can run the following `helm template` command with your Consul on Kubernetes
|
|||
$ helm template --release-name ${RELEASE_NAME} -s templates/client-snapshot-agent-serviceaccount.yaml hashicorp/consul
|
||||
```
|
||||
|
||||
### Configure the Vault Kubernetes auth role in the Consul on Kubernetes helm chart
|
||||
### Update the Consul on Kubernetes helm chart
|
||||
|
||||
Now that you have configured Vault, you can configure the Consul Helm chart to
|
||||
use the snapshot agent config in Vault:
|
||||
|
|
|
|||
|
|
@ -0,0 +1,257 @@
|
|||
---
|
||||
layout: docs
|
||||
page_title: Vault as the Webhook Certificate Provider for Consul Controller and Connect Inject on Kubernetes
|
||||
description: >-
|
||||
Configuring the Consul Helm chart to use TLS certificates issued by Vault for the Consul Controller and Connect Inject webhooks.
|
||||
---
|
||||
|
||||
# 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 normally fulfills the role of ensuring that a valid certificate is updated to the `mutatingwebhookconfiguration` of either 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](/docs/k8s/installation/vault/data-integration) section:
|
||||
|
||||
### Setup per Consul datacenter
|
||||
1. Create a Vault policy that authorizes the desired level of access to the secret.
|
||||
1. (Added) Create Vault PKI roles for controller and connect inject each that establish the domains that each is allowed to issue certificates for.
|
||||
1. Create Vault Kubernetes auth roles that link the policy to each Consul on Kubernetes service account that requires access.
|
||||
1. 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:
|
||||
1. Verify that you have completed the steps described in [Systems Integration](/docs/k8s/installation/vault/systems-integration) section of [Vault as a Secrets Backend](/docs/k8s/installation/vault).
|
||||
1. You should be familiar with the [Data Integration Overview](/docs/k8s/installation/vault/data-integration) section of [Vault as a Secrets Backend](/docs/k8s/installation/vault).
|
||||
1. Configure [Vault as the Server TLS Certificate Provider on Kubernetes](/docs/k8s/installation/vault/data-integration/server-tls)
|
||||
1. Configure [Vault as the Service Mesh Certificate Provider on Kubernetes](/docs/k8s/installation/vault/data-integration/connect-ca)
|
||||
1. Complete the [Bootstrapping the PKI Engine for Controller and Connect Inject Webhooks](#bootstrapping-the-pki-engine-for-controller-and-connect-inject-webhooks) section.
|
||||
|
||||
### Bootstrapping the PKI Engine for Controller and Connect Inject Webhooks
|
||||
|
||||
The first step is to bootstrap the Vault cluster. 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:
|
||||
|
||||
```shell-session
|
||||
$ vault secrets enable -path=controller pki
|
||||
```
|
||||
|
||||
```shell-session
|
||||
$ vault secrets enable -path=connect-inject pki
|
||||
```
|
||||
|
||||
* Tune the engine mounts to enable longer TTL:
|
||||
|
||||
```shell-session
|
||||
$ vault secrets tune -max-lease-ttl=87600h controller
|
||||
```
|
||||
|
||||
```shell-session
|
||||
$ vault secrets tune -max-lease-ttl=87600h connect-inject
|
||||
```
|
||||
|
||||
* Generate the root CA for each:
|
||||
|
||||
```shell-session
|
||||
$ vault write -field=certificate controller/root/generate/internal \
|
||||
common_name="<helm release name>-controller-webhook" \
|
||||
ttl=87600h
|
||||
```
|
||||
|
||||
```shell-session
|
||||
$ vault write -field=certificate connect-inject/root/generate/internal \
|
||||
common_name="<helm release name>-connect-injector" \
|
||||
ttl=87600h
|
||||
```
|
||||
## Setup per Consul datacenter
|
||||
You will need to preform the following steps for each datacenter that you would like to manage controller and connect inject webhook certificates in Vault. You will want to take care to create different names per datacenter for every pki mount, role, and policy.
|
||||
|
||||
### Create a Vault policy that authorizes the desired level of access to the secret
|
||||
To use Vault to issue controller or connect inject webhook certificates, you will need to create the Vault policies that will allow either controller or connect inject to access its respective certificate-issuing URL.
|
||||
|
||||
#### Create Vault Policies for the Controller and Connect Inject Webhook Certificates
|
||||
|
||||
-> **Note:** The PKI secret paths referenced by the Vault Policies below will be your `global.secretsBackend.vault.controller.tlsCert.secretName` and `global.secretsBackend.vault.connectInject.tlsCert.secretName` Helm values respectively.
|
||||
|
||||
The next step is to create a policy that allows `["create", "update"]` access to the
|
||||
[certificate issuing URL](https://www.vaultproject.io/api/secret/pki#generate-certificate) so Consul controller and connect inject can fetch a new certificate/key pair and provide it to the Kubernetes `mutatingwebhookconfiguration`. Issue the following commands to create the policy:
|
||||
|
||||
|
||||
```shell-session
|
||||
$ vault policy write controller-tls-policy - <<EOF
|
||||
path controller/issue/controller-role {
|
||||
capabilities = ["create", "update"]
|
||||
}
|
||||
EOF
|
||||
```
|
||||
|
||||
```shell-session
|
||||
$ vault policy write connect-inject-policy - <<EOF
|
||||
path connect-inject/issue/connect-inject-role {
|
||||
capabilities = ["create", "update"]
|
||||
}
|
||||
EOF
|
||||
```
|
||||
#### Create Vault Policies for the CA URL
|
||||
|
||||
-> **Note:** The PKI secret paths referenced by the Vault Policies below will be your `global.secretsBackend.vault.controller.caCert.secretName` and `global.secretsBackend.vault.connectInject.caCert.secretName` Helm values respectively.
|
||||
|
||||
Next, create a policy that allows `["read"]` access to the [CA URL](https://www.vaultproject.io/api/secret/pki#read-certificate). The policy is required so that Consul components can communicate with the Consul servers in order to fetch their auto-encryption certificates. Issue the following commands to create the policy:
|
||||
|
||||
```shell-session
|
||||
$ vault policy write controller-ca-policy - <<EOF
|
||||
path controller/cert/ca {
|
||||
capabilities = ["read"]
|
||||
}
|
||||
EOF
|
||||
```
|
||||
|
||||
```shell-session
|
||||
$ vault policy write connect-inject-ca-policy - <<EOF
|
||||
path connect-inject/cert/ca {
|
||||
capabilities = ["read"]
|
||||
}
|
||||
EOF
|
||||
```
|
||||
### Configure allowed domains for PKI certificates
|
||||
|
||||
Issue the following command to create a Vault role for the controller PKI engine and set the default parameters for issuing certificates:
|
||||
|
||||
```shell-session
|
||||
$ vault write controller/roles/controller-role \
|
||||
allowed_domains="<Allowed-domains-string>" \
|
||||
allow_subdomains=true \
|
||||
allow_bare_domains=true \
|
||||
allow_localhost=true \
|
||||
generate_lease=true \
|
||||
max_ttl="720h"
|
||||
```
|
||||
|
||||
Issue the following command to create a Vault role for the connect inject PKI engine and set the default parameters for issuing certificates:
|
||||
|
||||
```shell-session
|
||||
$ vault write connect-inject/roles/connect-inject-role \
|
||||
allowed_domains="<Allowed-domains-string>" \
|
||||
allow_subdomains=true \
|
||||
allow_bare_domains=true \
|
||||
allow_localhost=true \
|
||||
generate_lease=true \
|
||||
max_ttl="720h"
|
||||
```
|
||||
|
||||
To generate the `<Allowed-domains-string>` for each use the following script as a template:
|
||||
|
||||
```shell-session
|
||||
#!/bin/sh
|
||||
|
||||
# NAME is set to either the value from `global.name` from your Consul K8s value file, or your $HELM_RELEASE_NAME-consul
|
||||
export NAME=consulk8s
|
||||
# NAMESPACE is where the Consul on Kubernetes is installed
|
||||
export NAMESPACE=consul
|
||||
# DATACENTER is the value of `global.datacenter` from your Helm values config file
|
||||
export DATACENTER=dc1
|
||||
|
||||
echo allowed_domains_controller=\"${NAME}-controller-webhook,${NAME}-controller-webhook.${NAMESPACE},${NAME}-controller-webhook.${NAMESPACE}.svc,${NAME}-controller-webhook.${NAMESPACE}.svc.cluster.local\""
|
||||
|
||||
echo allowed_domains_connect_inject=\"${NAME}-connect-injector,${NAME}-connect-injector.${NAMESPACE},${NAME}-connect-injector.${NAMESPACE}.svc,${NAME}-connect-injector.${NAMESPACE}.svc.cluster.local\""
|
||||
```
|
||||
|
||||
### Create a Vault auth roles that link the policy to each Consul on Kubernetes service account that requires access
|
||||
|
||||
-> **Note:** The Vault auth roles below will be your `global.secretsBackend.vault.controllerRole` and `global.secretsBackend.vault.connectInjectRole` Helm values respectively.
|
||||
|
||||
|
||||
Finally, Kubernetes auth roles need to be created for controller and connect inject webhooks.
|
||||
|
||||
Role for Consul controller webhooks:
|
||||
```shell-session
|
||||
$ vault write auth/kubernetes/role/controller-role \
|
||||
bound_service_account_names=<Consul controller service account> \
|
||||
bound_service_account_namespaces=<Consul installation namespace> \
|
||||
policies=controller-ca-policy \
|
||||
ttl=1h
|
||||
```
|
||||
|
||||
To find out the service account name of the Consul controller,
|
||||
you can run:
|
||||
|
||||
```shell-session
|
||||
$ helm template --release-name ${RELEASE_NAME} --show-only templates/controller-serviceaccount.yaml hashicorp/consul
|
||||
```
|
||||
|
||||
Role for Consul connect inject webhooks:
|
||||
|
||||
```shell-session
|
||||
$ vault write auth/kubernetes/role/connect-inject-role \
|
||||
bound_service_account_names=<Consul connect inject service account> \
|
||||
bound_service_account_namespaces=<Consul installation namespace> \
|
||||
policies=connect-inject-ca-policy \
|
||||
ttl=1h
|
||||
```
|
||||
|
||||
To find out the service account name of the Consul connect inject, use the command below.
|
||||
```shell-session
|
||||
$ helm template --release-name ${RELEASE_NAME} --show-only templates/connect-inject-serviceaccount.yaml hashicorp/consul
|
||||
```
|
||||
|
||||
### Update the 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:
|
||||
|
||||
<CodeBlockConfig filename="values.yaml" linenumbers highlight="8,9,10,11,12,13,14,15,16,17,18,19">
|
||||
|
||||
```yaml
|
||||
global:
|
||||
secretsBackend:
|
||||
vault:
|
||||
enabled: true
|
||||
consulServerRole: "consul-server"
|
||||
consulClientRole: "consul-client"
|
||||
consulCARole: "consul-ca"
|
||||
controllerRole: "controller-role"
|
||||
connectInjectRole: "connect-inject-role"
|
||||
controller:
|
||||
caCert:
|
||||
secretName: "controller/cert/ca"
|
||||
tlsCert:
|
||||
secretName: "controller/issue/controller-role"
|
||||
connectInject:
|
||||
caCert:
|
||||
secretName: "connect-inject/cert/ca"
|
||||
tlsCert:
|
||||
secretName: "connect-inject/issue/connect-inject-role"
|
||||
tls:
|
||||
enabled: true
|
||||
enableAutoEncrypt: true
|
||||
caCert:
|
||||
secretName: "pki/cert/ca"
|
||||
server:
|
||||
serverCert:
|
||||
secretName: "pki/issue/consul-server"
|
||||
extraVolumes:
|
||||
- type: "secret"
|
||||
name: <vaultCASecret>
|
||||
load: "false"
|
||||
connectInject:
|
||||
enabled: true
|
||||
controller:
|
||||
enabled: true
|
||||
```
|
||||
|
||||
</CodeBlockConfig>
|
||||
|
||||
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:
|
||||
|
||||
```shell-session
|
||||
$ kubectl create secret generic vault-ca --from-file vault.ca=/path/to/your/vault/
|
||||
```
|
||||
|
|
@ -309,7 +309,7 @@ To use Vault as the Service Mesh Certificate Provider in Kubernetes, you must co
|
|||
1. Create a Vault policy that authorizes the desired level of access to the secrets.
|
||||
- Setup per Consul datacenter
|
||||
1. Create Vault Kubernetes auth roles that link the policy to each Consul on Kubernetes service account that requires access.
|
||||
1. Configure the Vault Kubernetes auth role in the Consul on Kubernetes helm chart.
|
||||
1. Update the Consul on Kubernetes helm chart.
|
||||
|
||||
### One time setup in Vault
|
||||
1. Store the ACL Replication Token, Gossip Encryption Key, and Root CA certificate secrets in Vault.
|
||||
|
|
@ -492,7 +492,7 @@ To use Vault as the Service Mesh Certificate Provider in Kubernetes, you must co
|
|||
```
|
||||
|
||||
#### Pre-installation for Secondary Datacenter (dc2)
|
||||
1. Configure the Vault Kubernetes auth role in the Consul on Kubernetes Helm chart. For secondary datacenter (dc2), you will need to get the address of the mesh gateway from the **primary datacenter (dc1)** cluster.
|
||||
1. Update the Consul on Kubernetes helm chart. For secondary datacenter (dc2), you will need to get the address of the mesh gateway from the **primary datacenter (dc1)** cluster.
|
||||
|
||||
Keep your Kubernetes context targeting dc1 and set the `MESH_GW_HOST` environment variable that you will use in the Consul Helm chart for secondary datacenter (dc2).
|
||||
|
||||
|
|
|
|||
|
|
@ -541,6 +541,10 @@
|
|||
{
|
||||
"title": "Snapshot Agent Config",
|
||||
"path": "k8s/installation/vault/data-integration/snapshot-agent-config"
|
||||
},
|
||||
{
|
||||
"title": "Webhook Certificates",
|
||||
"path": "k8s/installation/vault/data-integration/webhook-certs"
|
||||
}
|
||||
]
|
||||
},
|
||||
|
|
|
|||
Loading…
Reference in New Issue