An example repo structure for GitOps using:
Problem: "I can manage all my Kubernetes config in git, except Secrets."
Solution: Encrypt your Secret into a SealedSecret, which is safe to store. The SealedSecret can be decrypted only by the controller running in the target cluster and nobody else (not even the original author) is able to obtain the original Secret from the SealedSecret.
For more information on Sealed Secrets please see here.
Flux will apply the sealed secret on our cluster and the Bitnami Sealed Secrets controller will then decrypt it into a Kubernetes secret (see below).
.
├── keys
│ ├── dev.crt # The environment specific public key used for sealing secrets.
├── local-sealed # Kubernetes secrets which have already been sealed.
│ └── dev
├── local-toseal # Kubernetes secrets which are yet to be sealed.
│ └── dev
└── sealed-secrets # Sealed secrets to be reconciled by flux.
└── dev
A list of pre-requisites can be found here.
-
To configure this to work with your repository first read the steps here.
-
Create a cluster using
make cluster -
Install Flux and Bitnami Sealed Secrets using
make install-flux -
After following the prompts, flux will establish a connection to your repository and start reconciling.
-
The
sealed-secretscontroller will be deployed to thekube-systemnamespace. -
You will also need to add the public key from the sealed secrets' controller using
make get-public-key.
The following sections walks through the tests of creating different types of secrets.
To seal secrets for all environments run
$ make seal-all
To clean out local secrets for a single environment run:
$ make clean-<env>
To clean out all local secrets run:
$ make clean
Simply execute make destroy
Only files in local-toseal/<env> which have an extension .yaml will be sealed.
You can't change the metadata (e.g. namespace) of a sealed secret without re-sealing it since some form of checksum is performed when unsealing on the server, so if you change anything, you need to re-seal properly.