How do I secure Vault again after secret addition

Vault
1

I installed Vault with Helm. Then I have run

kubectl exec -ti vault-0 -n vault -- vault operator init
kubectl exec -ti vault-0 -n vault -- vault operator unseal ...
kubectl exec -ti vault-1 -n vault -- vault operator raft join http://vault-0.vault-internal:8200
kubectl exec -ti vault-1 -n vault -- vault operator unseal ...
kubectl exec -ti vault-2 -n vault -- vault operator raft join http://vault-0.vault-internal:8200
kubectl exec -ti vault-2 -n vault -- vault operator unseal ...

I login via

kubectl exec -ti vault-0 -n vault -- vault login

and enter the root token.

I add a secret plus Policy for Kubernetes like here.

My question is, now that it is unsealed and I am logged in, a malicious actor might come and run something like

kubectl exec -it vault-0 -n vault -- /bin/sh
vault kv get internal/database/config

to get the secret.

How can I protect myself from it?

2

First thing you should not use root token, 2nd use short lived token with low num uses, from specific cidr or ip, and provide only minimal acces through policy. If an attacker get access to k8s i wont worry much about the token, it is done, Vault only secure the secrets but if there are misconfigurations, exploits, vault cant help.

3

@tsiamer Many thanks for getting back to me.

Could you tell me whether there is some page or something, which helps me in this regard?

4

Here we go:

Read as well about other parameters, that should give you good start.

5

@tsiamer This will definitely prove to be very helpful.

Currently, I have exposed the service to the public at vault.my-domain.com. Likely, this is a very bad configuration. How could I make it safe enough that the other Kubernetes clusters can work with Vault and that I can connect to it with my local machine?

6

Have a look here On instance vault integration with multiple Kubernetes clusters and here what maxb suggested: https://computingforgeeks.com/how-to-integrate-multiple-kubernetes-clusters-to-vault-server/

7

@tsiamer Many thanks for your reply. I actually already came across the first the solution and managed to make it work.

However, I eventually resolved in exposing the vault service, from the cluster that carries vault, to the public via vault.my-domain.com, such that other services can access it just like in the links you provided above.

This works well and Vault distributes secrets to the right positions, but right now everyone can access it. Hence, I am a bit worried about it and ask myself if there is a better solution to it?

One solution I thought about is to restrict access to the service like this

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: vault-ingress
  annotations:
    kubernetes.io/ingress.class: nginx-ingress
    ingress.kubernetes.io/whitelist-source-range: 192.168.1.0
spec:
  rules:
    - host: www.vault.example.com
      http:
        paths:
          - path: /
            backend:
              serviceName: service-name
              servicePort: 80

However, also here I am not sure whether this is enough protection.