Published on 00/00/0000
Last updated on 00/00/0000
Published on 00/00/0000
Last updated on 00/00/0000
Share
Share
8 min read
Share
backyards install
? Install istio-operator (recommended). Press enter to accept Yes
? Install canary-operator (recommended). Press enter to accept No
? Install and run demo application (optional). Press enter to skip No
STRICT
:
❯ backyards mtls require mesh
INFO[0000] switched global mTLS to STRICT successfully
After this, we can check that mesh is configured with mTLS
turned on which applies to all applications in the cluster in Istio-enabled namespaces. You can change this if you would like to use another policy.
$ backyards mtls get mesh
mTLS rule for /mesh
Policy Targets MtlsMode
/default [] STRICT
vault-system
. You can enable Istio sidecar injection here as well, but Kubernetes won't be able to call back the webhook properly since mTLS is enabled (and Kubernetes is outside of the Istio mesh). To overcome this, apply a PERMISSIVE
Istio authentication policy to the vault-secrets-webhook
Service itself, so Kubernetes can call it back without Istio mutual TLS authentication.
$ kubectl create namespace vault-system
namespace/vault-system created
$ backyards sidecar-proxy auto-inject on vault-system
INFO[0002] auto sidecar injection successfully set to namespace default
$ backyards mtls allow vault-system/vault-secrets-webhook
INFO[0001] policy peers for vault-system/vault-secrets-webhook set successfully
mTLS rule for vault-system/vault-secrets-webhook
Policy Targets MtlsMode
vault-system/vault-secrets-webhook-rw6mc [vault-secrets-webhook] PERMISSIVE
helm repo add banzaicloud-stable https://kubernetes-charts.banzaicloud.com
helm upgrade --install vault-secrets-webhook banzaicloud-stable/vault-secrets-webhook --namespace vault-system
helm upgrade --install vault-operator banzaicloud-stable/vault-operator --namespace vault-system
Soon the webhook and the operator become up and running. Check that the istio-proxy
got injected into all Pods in vault-system
.kubectl create namespace vault
kubectl apply -f rbac.yaml -f cr-istio.yaml
$ kubectl get pods -n vault
NAME READY STATUS RESTARTS AGE
vault-0 3/3 Running 0 22h
vault-configurer-6458cc4bf-6tpkz 1/1 Running 0 22h
If you are writing your own Vault CR make sure that istioEnabled: true
is configured, this influences port naming so the Vault service port protocols are detected by Istio correctly.vault-secrets-webhook
can't inject Vault secrets into initContainers
in an Istio-enabled namespace when the STRICT
authentication policy is applied to the Vault service, because Istio needs a sidecar container to do mTLS properly, and in the phase when initContainers
are running the Pod doesn't have a sidecar yet. If you wish to inject into initContainers
as well, you need to apply a PERMISSIVE
authentication policy in the vault
namespace, since it has its own TLS certificate outside of Istio scope (so this is safe to do from networking security point of view).
$ backyards mtls allow vault
INFO[0001] policy peers for vault/ set successfully
mTLS rule for vault/
Policy Targets MtlsMode
vault/default [] PERMISSIVE
kubectl create namespace app
backyards sidecar-proxy auto-inject on app
kubectl apply -f app.yaml
app
itself and the istio-proxy
:
$ kubectl get pods -n app
NAME READY STATUS RESTARTS AGE
app-5df5686c4-sl6dz 2/2 Running 0 119s
$ kubectl logs -f -n app deployment/app app
time="2020-02-18T14:26:01Z" level=info msg="Received new Vault token"
time="2020-02-18T14:26:01Z" level=info msg="Initial Vault token arrived"
s3cr3t
going to sleep...
app
namespace by removing the istio-injection
label:
backyards sidecar-proxy auto-inject off app
backyards sidecar-proxy auto-inject on vault
vault
namespace, so they will get recreated with the istio-proxy
sidecar:
kubectl delete pods --all -n vault
$ kubectl get pods -n vault
NAME READY STATUS RESTARTS AGE
vault-0 4/4 Running 0 1m
vault-configurer-6d9b98c856-l4flc 2/2 Running 0 1m
kubectl delete pods --all -n app
app
container (1/1) and Vault access still works:
$ kubectl get pods -n app
NAME READY STATUS RESTARTS AGE
app-5df5686c4-4n6r7 1/1 Running 0 71s
$ kubectl logs -f -n app deployment/app
time="2020-02-18T14:41:20Z" level=info msg="Received new Vault token"
time="2020-02-18T14:41:20Z" level=info msg="Initial Vault token arrived"
s3cr3t
going to sleep...
backyards sidecar-proxy auto-inject on app
backyards sidecar-proxy auto-inject on vault
kubectl delete pods --all -n app
kubectl delete pods --all -n vault
$ kubectl logs -f -n app deployment/app
time="2020-02-18T15:04:03Z" level=info msg="Initial Vault token arrived"
time="2020-02-18T15:04:03Z" level=info msg="Renewed Vault Token"
s3cr3t
going to sleep...
Update: since releasingBank-Vaults 1.0, we also providecommercial support for Bank-Vaults. If you're interested in commercial support, or anything else from our suite of products, make sure you get in touch with us,here.If you're interested in contributing, check out the Bank-Vaults repository, or give us a GitHub star.
Learn more about Bank-Vaults:
- Secret injection webhook improvements
- Backing up Vault with Velero
- Vault replication across multiple datacenters
- Vault secret injection webhook and Istio
- HSM support
- Injecting dynamic configuration with templates
- OIDC issuer discovery for Kubernetes service accounts
- Show all posts related to Bank-Vaults
Get emerging insights on emerging technology straight to your inbox.
Discover why security teams rely on Panoptica's graph-based technology to navigate and prioritize risks across multi-cloud landscapes, enhancing accuracy and resilience in safeguarding diverse ecosystems.
The Shift is Outshift’s exclusive newsletter.
Get the latest news and updates on generative AI, quantum computing, and other groundbreaking innovations shaping the future of technology.