krogebry / ironbark-k8s-self-service

Self service portal for provisioning k8s namespaces
0 stars 2 forks source link

Secrets management #35

Open krogebry opened 4 months ago

krogebry commented 4 months ago

Overview

In order to properly secure secrets data we want to start using Vault.

There are essentially two ways to map secret data into a container using Vault:

The vault annotations is a fine way to go, but there's a draw back that most people don't realize that you only really get when you're doing this in production. Occasionally, the vault system will fail, and when that happens, none of your pods will come up because they're dependand on the vault service for key data.

On the plus side, this ensure that the only place your secret data is stored is in Vault. That's great and all, until your cluster shits the bed and you can't get anything to work.

This is where ESO comes in. The External Secrets Operator allows you to map things in a certain way where you end up with a k8s secret with your secret data. So, on one hand that does break the model where you have data in vault ( or AWS::SM, or whatever ), and in a k8s secret in the namespace. But it's a secret, and therefor it's protected more than just a normal object in k8s.

This also means two things:

Even if we're using a local vault service, I'd still prefer to do the "long way" with the ESO as to ensure that we have a functional environment. I would also suggest that we use the annotations way as well just get practice with how that works.

DoD

mistyayn commented 3 months ago

@krogebry am I on the right track with these for getting vault to run in the cluster?

https://developer.hashicorp.com/vault/tutorials/kubernetes/kubernetes-raft-deployment-guide

https://developer.hashicorp.com/vault/tutorials/operations/codify-mgmt-vault-terraform

krogebry commented 3 months ago

Yeah, more or less.