luxolus
/
open-vault
2
0
Fork 0
Code Issues 1 Pull Requests Releases Activity

doc: add agent inject documentation (#8032) 

* Add agent inject documentation

* Update layout

* Fix sidebar title

* Fix format

* Update formating

* Updates

* Convert table to list

* Add remaining doc

* Add note about namespace selector

* Fix page description

* Fix description error, clarify container doc

* Fix typos

* Update website/source/docs/platform/k8s/injector/index.html.md

Co-Authored-By: Clint <catsby@users.noreply.github.com>

* Update website/source/docs/platform/k8s/injector/index.html.md

Co-Authored-By: Clint <catsby@users.noreply.github.com>

* Update website/source/docs/platform/k8s/injector/examples.html.md

Co-Authored-By: Jim Kalafut <jkalafut@hashicorp.com>

* Update website/source/docs/platform/k8s/injector/examples.html.md

Co-Authored-By: Jim Kalafut <jkalafut@hashicorp.com>

* Update website/source/docs/platform/k8s/injector/index.html.md

Co-Authored-By: Jim Kalafut <jkalafut@hashicorp.com>

* Update website/source/docs/platform/k8s/injector/index.html.md

Co-Authored-By: Jim Kalafut <jkalafut@hashicorp.com>

* Update website/source/docs/platform/k8s/injector/installation.html.md

Co-Authored-By: Jim Kalafut <jkalafut@hashicorp.com>

* Update doc from feedback

* Update website/source/docs/platform/k8s/helm/configuration.html.md

Co-Authored-By: Becca Petrin <beccapetrin@gmail.com>

* Update website/source/docs/platform/k8s/helm/configuration.html.md

Co-Authored-By: Becca Petrin <beccapetrin@gmail.com>

* Update website/source/docs/platform/k8s/helm/configuration.html.md

Co-Authored-By: Becca Petrin <beccapetrin@gmail.com>

* Update website/source/docs/platform/k8s/helm/configuration.html.md

Co-Authored-By: Becca Petrin <beccapetrin@gmail.com>

* Update website/source/docs/platform/k8s/helm/configuration.html.md

Co-Authored-By: Becca Petrin <beccapetrin@gmail.com>

* Update website/source/docs/platform/k8s/helm/configuration.html.md

Co-Authored-By: Becca Petrin <beccapetrin@gmail.com>
This commit is contained in:
Jason O'Donnell 2019-12-18 13:44:14 -05:00 committed by GitHub
parent 1dcf698432
commit 36bf278ef7
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
5 changed files with 620 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

44
website/source/docs/platform/k8s/helm/configuration.html.md
View File

@ -31,6 +31,48 @@ and consider if they're appropriate for your deployment.
* `tlsDisable` (`boolean: true`) - When set to `true`, changes URLs from `https` to `http` (such as the `VAULT_ADDR=http://127.0.0.1:8200` environment variable set on the Vault pods).
* `injector` - Values that configure running a Vault Agent Injector Admission Webhook Controller within Kubernetes.
* `enabled` (`boolean: true`) - When set to `true`, the Vault Agent Injector Admission Webhook controller will be created.
* `image` (`string: "hashicorp/vault-k8s:0.1.0"`) - The name of the Docker image (including any tag) for `vault-k8s` project. **This should be pinned to a specific version when running in production.** Otherwise, other changes to the chart may inadvertently upgrade your admission controller.
* `imagePullPolicy` (`string: "IfNotPresent"`) - The pull policy for container images. The default pull policy is `IfNotPresent` which causes the Kubelet to skip pulling an image if it already exists.
* `imageVaultAgent` (`string: "vault:1.3.1"`) - The name of the Docker image (including any tag) for Vault Agent. This should be the official Vault image. **Vault 1.3.1+ is required by the admission controller**.
* `resources` (`string: ""`) - The resource requests and limits (CPU, memory, etc.) for each of the server. This should be a multi-line string mapping directly to a Kubernetes [ResourceRequirements](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.11/#resourcerequirements-v1-core) object. If this isn't specified, then the pods won't request any specific amount of resources.
<br>**Setting this is highly recommended.**
```yaml
# Resources are defined as a formatted multi-line string:
resources: |
requests:
memory: "10Gi"
limits:
memory: "10Gi"
```
* `namespaceSelector` (`string: ""`) - The selector used by the admission webhook controller to limit what namespaces where injection can happen. If set to null, all non-system namespaces are eligible for injection.
```yaml
# Selectors are defined as a formatted multi-line string.
# In this example, all namespaces with the label "injection: enabled" are eligible:
namespaceSelector: |
matchLabels:
injection: enabled
```
* `certs` - The certs section configures how the webhook TLS certs are configured. These are the TLS certs for the Kube apiserver communicating to the webhook. By default, the injector will generate and manage its own certs, but this requires the ability for the injector to update its own `MutatingWebhookConfiguration`. In a production environment, custom certs should probably be used. Configure the values below to enable this.
* `secretName` (`string: ""`) - secretName is the name of the Kubernetes secret that has the TLS certificate and private key to serve the injector webhook. If this is null, then the injector will default to its automatic management mode.
* `caBundle` (`string: ""`) - The PEM-encoded CA public certificate bundle for the TLS certificate served by the injector. This must be specified as a string and can't come from a secret because it must be statically configured on the Kubernetes `MutatingAdmissionWebhook` resource. This only needs to be specified if `secretName` is not null.
* `certName` (`string: "tls.crt"`) - The name of the certificate file within the `secretName` secret.
* `keyName` (`string: "tls.key"`) - The name of the key file within the `secretName` secret.
* `server` - Values that configure running a Vault server within Kubernetes.
* `resources` (`string: null`) - The resource requests and limits (CPU, memory, etc.) for each of the server. This should be a multi-line string mapping directly to a Kubernetes [ResourceRequirements](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.11/#resourcerequirements-v1-core) object. If this isn't specified, then the pods won't request any specific amount of resources.
@ -85,7 +127,7 @@ and consider if they're appropriate for your deployment.
* `authDelegator` - Values that configure the Cluster Role Binding attached to the Vault service account.
- `enabled` (`boolean: false`) - When set to `true`, a Cluster Role Binding will be bound to the Vault service account. This Cluster Role Binding has the necessary privileges for Vault to use the [Kubernetes Auth Method](/docs/auth/kubernetes.html).
- `enabled` (`boolean: true`) - When set to `true`, a Cluster Role Binding will be bound to the Vault service account. This Cluster Role Binding has the necessary privileges for Vault to use the [Kubernetes Auth Method](/docs/auth/kubernetes.html).
* `extraEnvironmentVars` - The extra environment variables to be applied to the Vault server. This should be a multi-line key/value string.

237
website/source/docs/platform/k8s/injector/examples.html.md Normal file
View File

@ -0,0 +1,237 @@
---
layout: "docs"
page_title: "Vault Agent Sidecar Injector Examples"
sidebar_current: "docs-platform-k8s-injector-examples"
sidebar_title: "Examples"
description: |-
This section documents examples of using the Vault Agent Injector.
---
# Vault Agent Injector Examples
The following are different configuration examples to support a variety of
deployment models.
~> A common mistake is to set the annotation on the Deployment or other resource.
Ensure that the injector annotations are specified on the pod specification when
using higher level constructs such as deployments, jobs or statefulsets.
## Before Using the Vault Agent Injector
Before applying Vault Agent injection annotations to pods, the following requirements
should be satisfied:
* Kubernetes auth method should be configured and enabled in Vault,
* Pod should have a service account,
* desired secrets exist within Vault,
* the service account should be bound to a Vault role with a policy enabling access to desired secrets.
For more information on configuring the Vault Kubernetes auth method,
[see the official documentation](/docs/auth/kubernetes.html#configuration).
## Debugging
If an error occurs with a mutation request, Kubernetes will attach the error to the
owner of the pod. Check the following for errors:
* If the pod was created by a deployment or statefulset, check for errors in the `replicaset`
that owns the pod.
* If the pod was created by a job, check the `job` for errors.
## Patching Existing Pods
To patch existing pods, a Kubernetes patch can be applied to add the required annoations
to pods. When applying a patch, the pods will be rescheduled.
First, create the patch:
```bash
cat <<EOF >> ./patch.yaml
spec:
template:
metadata:
annotations:
vault.hashicorp.com/agent-inject: "true"
vault.hashicorp.com/agent-inject-status: "update"
vault.hashicorp.com/agent-inject-secret-db-creds: "database/creds/db-app"
vault.hashicorp.com/agent-inject-template-db-creds: |
{{- with secret "database/creds/db-app" -}}
postgres://{{ .Data.username }}:{{ .Data.password }}@postgres:5432/appdb?sslmode=disable
{{- end }}
vault.hashicorp.com/role: "db-app"
vault.hashicorp.com/ca-cert: "/vault/tls/ca.crt"
vault.hashicorp.com/client-cert: "/vault/tls/client.crt"
vault.hashicorp.com/client-key: "/vault/tls/client.key"
vault.hashicorp.com/tls-secret: "vault-tls-client"
EOF
```
Next, apply the patch:
```bash
kubectl patch deployment <MY DEPLOYMENT> --patch "$(cat patch.yaml)"
```
The pod should now be rescheduled with additional containers. The pod can be inspected
using the `kubectl describe` command:
```bash
kubectl describe pod <name of pod>
```
## Deployments, StatefulSets, etc.
The annotations for configuring Vault Agent injection must be on the pod
specification. Since higher level resources such as Deployments wrap pod
specification templates, Vault Agent Injector can be used with all of these
higher level constructs, too.
An example Deployment below shows how to enable Vault Agent injection:
```yaml
---
apiVersion: v1
kind: ServiceAccount
metadata:
name: app-example
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: app-example-deployment
spec:
replicas: 1
selector:
matchLabels:
app: app-example
template:
metadata:
labels:
app: app-example
annotations:
vault.hashicorp.com/agent-inject: "true"
vault.hashicorp.com/agent-inject-secret-db-creds: "database/creds/db-app"
vault.hashicorp.com/agent-inject-template-db-creds: |
{{- with secret "database/creds/db-app" -}}
postgres://{{ .Data.username }}:{{ .Data.password }}@postgres:5432/appdb?sslmode=disable
{{- end }}
vault.hashicorp.com/role: "db-app"
vault.hashicorp.com/ca-cert: "/vault/tls/ca.crt"
vault.hashicorp.com/client-cert: "/vault/tls/client.crt"
vault.hashicorp.com/client-key: "/vault/tls/client.key"
vault.hashicorp.com/tls-secret: "vault-tls-client"
spec:
containers:
- name:app
image: "app:1.0.0"
serviceAccountName: app-example
```
## ConfigMap Example
The following example creates a deployment that mounts a Kubernetes ConfigMap
containing Vault Agent configuration files. For a complete list of the Vault
Agent configuration settings, [see the Agent documentation](/docs/agent/template/index.html#vault-agent-templates).
```yaml
---
apiVersion: v1
kind: ServiceAccount
metadata:
name: app-example
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: app-example-deployment
spec:
replicas: 1
selector:
matchLabels:
app: app-example
template:
metadata:
labels:
app: app-example
annotations:
vault.hashicorp.com/agent-inject: "true"
vault.hashicorp.com/agent-configmap: "my-configmap"
vault.hashicorp.com/tls-secret: "vault-tls-client"
spec:
containers:
- name:app
image: "app:1.0.0"
serviceAccountName: app-example
---
apiVersion: v1
kind: ConfigMap
metadata:
name: my-configmap
agent-config
app: app-example
data:
config.hcl: |
"auto_auth" = {
"method" = {
"config" = {
"role" = "db-app"
}
"type" = "kubernetes"
}
"sink" = {
"config" = {
"path" = "/home/vault/.token"
}
"type" = "file"
}
}
"exit_after_auth" = false
"pid_file" = "/home/vault/.pid"
"template" = {
"contents" = "{{- with secret "database/creds/db-app" -}}postgres://{{ .Data.username }}:{{ .Data.password }}@postgres:5432/mydb?sslmode=disable{{- end }}"
"destination" = "/vault/secrets/db-creds"
}
"vault" = {
"address" = "https://vault.demo.svc.cluster.local:8200"
"ca_cert" = "/vault/tls/ca.crt"
"client_cert" = "/vault/tls/client.crt"
"client_key" = "/vault/tls/client.key"
}
config-init.hcl: |
"auto_auth" = {
"method" = {
"config" = {
"role" = "db-app"
}
"type" = "kubernetes"
}
"sink" = {
"config" = {
"path" = "/home/vault/.token"
}
"type" = "file"
}
}
"exit_after_auth" = true
"pid_file" = "/home/vault/.pid"
"template" = {
"contents" = "{{- with secret "database/creds/db-app" -}}postgres://{{ .Data.username }}:{{ .Data.password }}@postgres:5432/mydb?sslmode=disable{{- end }}"
"destination" = "/vault/secrets/db-creds"
}
"vault" = {
"address" = "https://vault.demo.svc.cluster.local:8200"
"ca_cert" = "/vault/tls/ca.crt"
"client_cert" = "/vault/tls/client.crt"
"client_key" = "/vault/tls/client.key"
}
```

268
website/source/docs/platform/k8s/injector/index.html.md Normal file
View File

@ -0,0 +1,268 @@
---
layout: "docs"
page_title: "Agent Sidecar Injector Overview"
sidebar_current: "docs-platform-k8s-injector"
sidebar_title: "Agent Injector"
description: |-
The Vault Agent Sidecar Injector is a Kubernetes admission webhook that adds Vault Agent containers to pods for consuming Vault secrets.
---
# Agent Sidecar Injector
The Vault Agent Injector alters pod specifications to include Vault Agent
containers that render Vault secrets to a shared memory volume using
[Vault Agent Templates](/docs/agent/template/index.html).
By rendering secrets to a shared volume, containers within the pod can consume
Vault secrets without being Vault aware.
The injector is a [Kubernetes Mutation Webhook Controller](https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/).
The controller intercepts pod events and applies mutations to the pod if annotations exist within
the request. This functionality is provided by the [vault-k8s](https://github.com/hashicorp/vault-k8s)
project and can be automatically installed and configured using the
[Vault Helm](https://github.com/hashicorp/vault-helm) chart.
## Overview
The Vault Agent Injector works by intercepting pod `CREATE` and `UPDATE`
events in Kubernetes. The controller parses the event and looks for the metadata
annotation `vault.hashicorp.com/agent-inject: true`. If found, the controller will
alter the pod specification based on other annotations present.
### Mutations
At a minimum, every container in the pod will be configured to mount a shared
memory volume. This volume is mounted to `/vault/secrets` and will be used by the Vault
Agent containers for sharing secrets with the other containers in the pod.
Next, two types of Vault Agent containers can be injected: init and sidecar. The
init container will prepopulate the shared memory volume with the requested
secrets prior to the other containers starting. The sidecar container will
continue to authenticate and render secrets to the same location as the pod runs.
Using annotations, the initialization and sidecar containers may be disabled.
Last, two additional types of volumes can be optionally mounted to the Vault Agent
containers. The first is secret volume containing TLS requirements such as client
and CA (certificate authority) certificates and keys. This volume is useful when
communicating and verifying the Vault server's authenticity using TLS. The second
is a configuration map containing Vault Agent configuration files. This volume is
useful to customize Vault Agent beyond what the provided annotations offer.
### Authenticating with Vault
The primary method of authentication with Vault when using the Vault Agent Injector
is the service account attached to the pod. At this time, no other authentication
method is supported by the controller.
The service account must be bound to a Vault role and a policy granting access to
the secrets desired.
A service account must be present to use the Vault Agent Injector. It is *not*
recommended to bind Vault roles to the default service account provided to pods
if no service account is defined.
### Requesting Secrets
There are two methods of configuring the Vault Agent containers to render secrets:
* the `vault.hashicorp.com/agent-inject-secret` annotation, or
* a configuration map containing Vault Agent configuration files.
Only one of these methods may be used at any time.
#### Secrets via Annotations
To configure secret injection using annotations, the user must supply:
* one or more _secret_ annotations, and
* the Vault role used to access those secrets.
The annotation must have the format:
```yaml
vault.hashicorp.com/agent-inject-secret-<unique-name>: /path/to/secret
```
The unique name will be the filename of the rendered secret and must be unique if
multiple secrets are defined by the user. For example, consider the following
secret annotations:
```yaml
vault.hashicorp.com/agent-inject-secret-foo: database/roles/app
vault.hashicorp.com/agent-inject-secret-bar: consul/creds/app
vault.hashicorp.com/role: "app"
```
The first annotation will be rendered to `/vault/secrets/foo` and the second
annotation will be rendered to `/vault/secrets/bar`.
It's possible to set the file format of the using the annotation. For example the
following secret will be rendered to `/vault/secrets/foo.txt`:
```yaml
vault.hashicorp.com/agent-inject-secret-foo.txt: database/roles/app
vault.hashicorp.com/role: "app"
```
The secret unique name must consist of alphanumeric characters, `.`, `_` or `-`.
##### Secret Templates
~> Vault Agent uses the Consul Template project to render secrets. For more information
on writing templates, see the [Consul Template documentation](https://github.com/hashicorp/consul-template).
How the secret is rendered to the file is also configurable. To configure the template
used, the user must supply a _template_ annotation using the same unique name of
the secret. The annotation must have the following format:
```yaml
vault.hashicorp.com/agent-inject-template-<unique-name>: |
<
TEMPLATE
HERE
>
```
For example, consider the following:
```yaml
vault.hashicorp.com/agent-inject-secret-foo: "database/roles/app"
vault.hashicorp.com/agent-inject-template-foo: |
{{- with secret "database/creds/db-app" -}}
postgres://{{ .Data.username }}:{{ .Data.password }}@postgres:5432/mydb?sslmode=disable
{{- end }}
vault.hashicorp.com/role: "app"
```
The rendered secret would look like this within the container:
```bash
$ cat /vault/secrets/foo
postgres://v-kubernet-pg-app-q0Z7WPfVN:A1a-BUEuQR52oAqPrP1J@postgres:5432/mydb?sslmode=disable
```
~> The default left and right template delimiters are `{{` and `}}`.
If no template is provided the following generic template is used:
```
{{ with secret "/path/to/secret" }}
{{ range $k, $v := .Data }}
{{ $k }}: {{ $v }}
{{ end }}
{{ end }}
```
For example, the following annotation will use the default template to render
PostgreSQL secrets found at the configured path:
```yaml
vault.hashicorp.com/agent-inject-secret-foo: "database/roles/pg-app"
vault.hashicorp.com/role: "app"
```
The rendered secret would look like this within the container:
```bash
$ cat /vault/secrets/foo
password: A1a-BUEuQR52oAqPrP1J
username: v-kubernet-pg-app-q0Z7WPfVNqqTJuoDqCTY-1576529094
```
#### Vault Agent Configuration Map
For advanced use cases, it may be required to define Vault Agent configuration
files to mount instead of using secret and template annotations. The Vault Agent
Injector supports mounting ConfigMaps by specifying the name using the `vault.hashicorp.com/agent-configmap`
annotation. The configuration files will be mounted to `/vault/configs`.
The configuration map must contain either one or both of the following files:
* `config-init.hcl` used by the init container. This must have `exit_after_auth` set to `true`.
* `config.hcl` used by the sidecar container. This must have `exit_after_auth` set to `false`.
An example of mounting a Vault Agent configmap [can be found here](/docs/platforms/k8s/injector/examples.html#configmap-example).
## Annotations
* `vault.hashicorp.com/agent-inject` - configures whether injection is explicitly
enabled or disabled for a pod. This should be set to a `true` or `false` value.
Defaults to `false`.
* `vault.hashicorp.com/agent-inject-status` - blocks further mutations
by adding the value `injected` to the pod after a successful mutation.
* `vault.hashicorp.com/agent-inject-secret` - configures Vault Agent
to retrieve the secrets from Vault required by the container. The name of the
secret is any unique string after `vault.hashicorp.com/agent-inject-secret-`,
such as `vault.hashicorp.com/agent-inject-secret-foobar`. The value is the path
in Vault where the secret is located.
* `vault.hashicorp.com/agent-inject-template` - configures Vault Agent
what template to use for rendering the secrets. The name of the template is any
unique string after `vault.hashicorp.com/agent-inject-template-`, such as
`vault.hashicorp.com/agent-inject-template-foobar`. This should map to the same
unique value provided in `vault.hashicorp.com/agent-inject-secret-`. If not provided,
a default generic template is used.
* `vault.hashicorp.com/role` - configures the Vault role used by the Vault Agent
auto-auth method. Required when `vault.hashicorp.com/agent-configmap` is not set.
* `vault.hashicorp.com/agent-configmap` - name of the configuration map where Vault
Agent configuration file and templates can be found.
* `vault.hashicorp.com/agent-pre-populate` - configures whether an init container
is included to pre-populate the shared memory volume with secrets prior to the
containers starting.
* `vault.hashicorp.com/agent-pre-populate-only` - configures whether an init container
is the only injected container. If true, no sidecar container will be injected
at runtime of the pod.
* `vault.hashicorp.com/agent-image` - name of the Vault docker image to use. This
value overrides the default image configured in the controller and is usually
not needed. Defaults to `vault:1.3.1`.
* `vault.hashicorp.com/service` - name of the Vault service to use. This value
overrides the default service configured in the controller and is usually not
needed.
* `vault.hashicorp.com/agent-limits-cpu` - configures the CPU limits on the Vault
Agent containers. Defaults to `500m`.
* `vault.hashicorp.com/agent-limits-mem` - configures the memory limits on the Vault
Agent containers. Defaults to `128Mi`.
* `vault.hashicorp.com/agent-requests-cpu` - configures the CPU requests on the
Vault Agent containers. Defaults to `250m`.
* `vault.hashicorp.com/agent-requests-mem` - configures the memory requests on the
Vault Agent containers. Defaults to `64Mi`.
* `vault.hashicorp.com/tls-secret` - name of the Kubernetes secret containing TLS
Client and CA certificates and keys. This is mounted to `/vault/tls`.
* `vault.hashicorp.com/tls-server-name` - name of the Vault server to verify the
authenticity of the server when communicating with Vault over TLS.
* `vault.hashicorp.com/tls-skip-verify` - if true, configures the Vault Agent to
skip verification of Vault's TLS certificate. It's not recommended to set this
value to true in a production environment.
* `vault.hashicorp.com/ca-cert` - path of the CA certificate used to verify Vault's
TLS.
* `vault.hashicorp.com/ca-key` - path of the CA public key used to verify Vault's
TLS.
* `vault.hashicorp.com/client-cert` - path of the client certificate used when
communicating with Vault via mTLS.
* `vault.hashicorp.com/client-key` - path of the client public key used when communicating
with Vault via mTLS.
* `vault.hashicorp.com/client-max-retries` - configures number of Vault Agent retry
attempts when 5xx errors are encountered. Defaults to 2.
* `vault.hashicorp.com/client-timeout` - configures the request timeout threshold,
in seconds, of the Vault Agent when communicating with Vault. Defaults to `60s`
and accepts value types of `60`, `60s` or `1m`.

65
website/source/docs/platform/k8s/injector/installation.html.md Normal file
View File

@ -0,0 +1,65 @@
---
layout: "docs"
page_title: "Agent Sidecar Injector Installation"
sidebar_current: "docs-platform-k8s-injector-installation"
sidebar_title: "Installation"
description: |-
The Vault Agent Sidecar Injector can be installed using Vault Helm.
---
# Installing the Agent Injector
The following are the different methods of installing the Agent Injector in
Kubernetes.
~> The Vault Agent Injector requires Vault 1.3.1.
To install the Vault Agent injector, enable the injection feature using
[Helm values](/docs/platform/k8s/helm/configuration.html) and
upgrade the installation using `helm upgrade` for existing installs or
`helm install` for a fresh install.
To install a new instance of Vault and the Vault Agent Injector, run the following:
```bash
helm install --name=vault \
--set="injector.enabled=true" \
https://github.com/hashicorp/vault-helm/archive/v0.3.0.tar.gz
```
Other values in the Helm chart can be used to limit the namespaces the injector
runs in, TLS options and more.
## TLS Options
Admission webhook controllers require TLS to run within Kubernetes. At this time
the Vault Agent Injector supports two TLS options:
* Auto TLS generation (default)
* Manual TLS
### Auto TLS
By default, the Vault Agent Injector will bootstrap TLS by generating a certificate
authority and creating a certificate/key to be used by the controller. If using
Vault Helm, the chart will automatically create the neccessary DNS entries for the
controller's service used to verify the certificate.
### Manual TLS
If desired, users can supply their own TLS certificates, key and certificate authority.
The following is required to configure TLS manually:
* Server certificate/key
* Base64 PEM encoded Certificate Authority bundle
For more information on configuring manual TLS, see the [Vault Helm cert values](/docs/platform/k8s/helm/configuration.html#certs).
## Namespace Selector
By default, the Vault Agent Injector will process all namespaces in Kubernetes except
the system namespaces `kube-system` and `kube-public`. To limit what namespaces
the injector can work in a namespace selector can be defined to match labels attached
to namespaces.
For more information on configuring namespace selection, see the [Vault Helm namespaceSelector value](/docs/platform/k8s/helm/configuration.html#namespaceselector).

7
website/source/layouts/docs.erb
View File

@ -349,6 +349,13 @@
'examples'
]
},
{
category: 'injector',
content: [
'installation',
'examples'
]
},
]
},
{