First thing that needs to be said clearly: kubernetes Secret
API object/resource != Hashicorp Vault secrets, that you can use with kubernetes. If you use first = you don't youse the latter.
So basically there is no way to manage Kubernetes Secrets
by Hashicorp Vault. Instead of using kubernetes Secret
object to store sensitive data, consumed by your Pods
you use for that purpose Hahicorp Vault. As vault secrets can be injected directly into Pods
, you don't need to additionally mount them as volumes as in your example.
If you want to integrate Hashicorp Vault instance, installed on a separate cluster, the whole setup is described here.
If you want to deploy an app with hard-coded external Vault address, the official Hashicorp Vault documentation also explains how to do that:
The most direct way for a pod within the cluster to address Vault is
with a hard-coded network address defined within the application code
or provided as an environment variable. We've created and published a
web application that you will deploy with the Vault address overriden.
First, create a Kubernetes service account for the pods to use to
authenticate.
ServiceAccount metadata: name: internal-app EOF
Create a deployment with this web application that sets the
VAULT_ADDR
to EXTERNAL_VAULT_ADDR
.
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: devwebapp
labels:
app: devwebapp
spec:
replicas: 1
selector:
matchLabels:
app: devwebapp template:
metadata:
labels:
app: devwebapp
spec:
serviceAccountName: internal-app
containers:
- name: app
image: burtlo/devwebapp-ruby:k8s
imagePullPolicy: Always
env:
- name: VAULT_ADDR
value: "http://$EXTERNAL_VAULT_ADDR:8200" EOF
The web application, targeting the external Vault, is deployed as a
pod within the default namespace.
Get all the pods within the default namespace.
STATUS RESTARTS AGE devwebapp-68cc55948b-w9745 1/1 Running
0 4m
Wait until the devwebapp
pod reports that is running and ready
(1/1
).
Request content served at localhost:8080
from within the devwebapp
pod.
$(kubectl get pod -l app=devwebapp -o jsonpath="{.items[0].metadata.name}") \
-- curl -s localhost:8080 ; echo
The result displays the secret is defined at the path
secret/data/devwebapp/config
.
{"password"=>"salsa", "username"=>"giraffe"}
The web application authenticates with the external Vault server using
the root token and returns the secret defined at the path
secret/data/devwebapp/config
. This hard-coded approach is an
effective solution if the address to the Vault server does not change.
It's just one example among at least a few available approaches. Alternatively you may want to Deploy service and endpoints to address an external Vault or Install the Vault Helm chart configured to address an external Vault. As you can read in documentation:
The Vault Helm chart can deploy only the Vault Agent Injector service
configured to target an external Vault. The injector service enables
the authentication and secret retrieval for the applications, by
adding Vault Agent containers as they are written to the pod
automatically when a deployment includes specific annotations.
You may also want to take a look at the following articles:
Managing Secrets in Kubernetes with Vault by HashiCorp
Injecting Vault Secrets Into Kubernetes Pods via a Sidecar
Injecting Secrets into Kubernetes Pods via Vault Helm Sidecar
And many more related with using Hashicorp Vault with Kubernetes.