A UI on top of sealed-secrets - deploy anywhere with any number of public sealing keys, and allow anyone to seal secrets to be deployed to your Kubernetes clusters.
The default usage of sealed-secrets requires taking an entire Secret object and using the kubeseal binary and a connection to the target Kubernetes cluster to create a new SealedSecret. While this is great for Kubernetes admins that routinely deploy and update entire secrets, it's a bit less ideal for DevOps or Platform teams that want to allow Software Engineers to deploy their workloads to Kubernetes without knowing much about Kubernetes, sometimes even without having access to the sealed-secrets controller running in the cluster.
Kubeseal UI can be deployed anywhere, and will then offer users the possibility to input their secret value and required parameters (e.g. namespace and name of the SealedSecret resource). The resulting sealed value can then be added e.g. to an existing SealedSecret in a YAML file in a repository.
- Deploy the provided docker image wherever you want, and provide the
BUCKET_URLenvironment variable with a url to a public GCS Bucket (gs://...) - Into this bucket, put the public signing keys generated by the sealed-secrets controller in your cluster(s). You can get the last active key for example by using the following command:
kubectl get secret -n <NAMESPACE_OF_SEALED_SECRETS_CONTROLLER> -lsealedsecrets.bitnami.com/sealed-secrets-key=active -ojson | jq -r '.items[0].data["tls.crt"]' | base64 -d > <CLUSTER_NAME>.txt - Open the UI - you will see a list of available clusters, named based on the files you uploaded to the bucket
- Input your parameters, and submit the form
- The backend of the UI will now take your parameters and pass them to the
kubesealbinary with your public signing key, and return the sealed value - Put this value into a
SealedSecretresource and deploy it to your target cluster
At the current stage of development, the bucket with the signing keys must be public, private buckets are not supported. Given that you are only uploading the public signing keys which do not allow decryption of your secrets, this should not pose a security risk. If you'd like to anyway use a private bucket, or any other way of supplying the signing keys, PRs are welcome :)
Local development is dockerized, you'll need Docker and docker-compose installed. Run make init to run through the install process and start the dev container. Run make stop to stop everything, make start to start up again, and make logs for logs.
Dependencies are being kept up to date automatically by renovate, and a new docker image is released on every main build. Use latest if you always want to run the current version.