423acfd4dd
* Updates the k8s helm platform docs - Updates to talk about the external mode - Updates the helm install overview to show that the releases can also be the way to install - Rewrites the how-to to include showing how to start in each mode - Each mode that has a guide links off to a guide - Re-organizes the Unseal and Init to a section and places all the various other unseals underneath it - Moves updating below the unseal and init - Shows some basic usage of the helm CLI with a value and file override * Adds learn links for k8s index pages * Adds helm dev and external vault examples While the dev one may seem obvious I think that it's incredibly useful to cover our bases if this is to be reference documentation. I thought maybe the example could have ingress support for UI but do not have the experience to recommend it. * Adds helm docs example dev and external - places the development first as it feels like the starting point for some. - places the external after HA Co-authored-by: Vishal Nayak <vishalnayak@users.noreply.github.com>
43 lines
2 KiB
Plaintext
43 lines
2 KiB
Plaintext
---
|
|
layout: docs
|
|
page_title: Kubernetes
|
|
sidebar_title: Kubernetes
|
|
description: This section documents the official integration between Vault and Kubernetes.
|
|
---
|
|
|
|
# Kubernetes
|
|
|
|
Vault can be deployed into Kubernetes using the official HashiCorp Vault Helm chart.
|
|
The Helm chart allows users to deploy Vault in various configurations:
|
|
|
|
- Dev: a single in-memory Vault server for testing Vault
|
|
- Standalone (default): a single Vault server persisting to a volume using the file storage backend
|
|
- High-Availability (HA): a cluster of Vault servers that use an HA storage backend such as Consul (default)
|
|
- External: a Vault Agent Injector server that depends on an external Vault server
|
|
|
|
## Use Cases
|
|
|
|
**Running a Vault Service:** The Vault server cluster can run directly on Kubernetes.
|
|
This can be used by applications running within Kubernetes as well as external to
|
|
Kubernetes, as long as they can communicate to the server via the network.
|
|
|
|
**Accessing and Storing Secrets:** Applications using the Vault service running in
|
|
Kubernetes can access and store secrets from Vault using a number of different
|
|
[secret engines](/docs/secrets) and [authentication methods](/docs/auth).
|
|
|
|
**Running a Highly Available Vault Service:** By using pod affinities, highly available
|
|
backend storage (such as Consul) and [auto-unseal](/docs/concepts/seal#auto-unseal),
|
|
Vault can become a highly available service in Kubernetes.
|
|
|
|
**Encryption as a Service:** Applications using the Vault service running in Kubernetes
|
|
can leverage the [Transit secret engine](/docs/secrets/transit)
|
|
as "encryption as a service". This allows applications to offload encryption needs
|
|
to Vault before storing data at rest.
|
|
|
|
**Audit Logs for Vault:** Operators can choose to attach a persistent volume
|
|
to the Vault cluster which can be used to [store audit logs](/docs/audit).
|
|
|
|
**And more!** Vault can run directly on Kubernetes, so in addition to the
|
|
native integrations provided by Vault itself, any other tool built for
|
|
Kubernetes can choose to leverage Vault.
|