The missing part of Sealed Secrets. 🔐
kubeseal-convert
aims to reduce the friction of importing secrets from a pre-existing secret management systems (e.g. Vault, AWS Secrets Manager, etc..) into a SealedSecret
.
Instead of:
- Going into AWS Secret Manager
- Retrieve the secret who needs to be migrated
- Create a "normal" k8s secret
- Fill out the values on the secret
- Run
kubeseal
Just run kubeseal-convert
with the secret path.
Same as the kubeseal
command, kubeseal-convert
is un-opinionated. It won't commit the secret to Git, apply it to the cluster, or save it on a specific path.
The SealedSecret
will be printed to STDOUT
. You can run it as is, as part of CI, or as part of a Job.
./kubeseal-convert <SECRETS_STORE> <PATH> --namespace <NS_NAME> --name <SECRET_NAME>
Name | Description | Require | Type |
---|---|---|---|
-n , --name |
The Sealed Secret name. | V |
string |
--namespace |
The Sealed Secret namespace. If not specified, taken from k8s context. | string |
|
-a , --annotations |
Sets k8s annotations. KV pairs, comma separated. | []string |
|
-l , --labels |
Sets k8s labels. KV pairs, comma separated. | []string |
|
--raw |
Use Kubeseal raw mode. | bool |
|
-t , --timeout |
Set timeout to the secret fetch. Default: 30 | int |
|
-d , --debug |
Run in debug mode. | bool |
|
-h , --help |
Display help. | none |
|
-v , --version |
Display version. | none |
✅ AWS Secrets Manager
✅ Hashicorp Vault
✅ Azure Key Vault - Contributed by @kroonprins
✅ Google Secrets Manager
The AWS client rely on AWS local configuration variables - config file, environment variables, etc.
In order to work with the Vault provider, two environment variables needs to be set - VAULT_TOKEN
and VAULT_ADDR
.
Currently, only kv-v2
is supported.
The <SECRETS_STORE>
should contain the vault name from the vault full uri https://<SECRETS_STORE>.vault.azure.net
.
Authentication to the vault happens either via environment variables, managed identity, or via the az cli (az login
).
It's highly recommended to use the full secret format: projects/<PROJECT_ID>/secrets/<SECRET_NAME>/versions/<VERSION>
If not, kubeseal-convert
will try to extract the project ID from the default credentials chain, and will use the latest version of the secret.
- Go version 1.22+
make
command installedkubeseal
command installed, and a valid communication to the Sealed Secrets controller.
- Clone this repository
git clone https://github.com/EladLeev/kubeseal-convert && cd kubeseal-convert
- Build using Makefile
make build
- [optional] Set up local env for testing
make init-dev
- [optional] Run the example
./kubeseal-convert sm MyTestSecret --namespace test-ns --name test-secret --annotations converted-by=kubeseal-convert,env=dev --labels test=abc > secret.yaml
or
./kubeseal-convert vlt "mydomain/data/MyTestSecret" --namespace test-ns --name test-secret --annotations converted-by=kubeseal-convert,src=vault --labels test=abc > secret.yaml
This will:
- Retrieve a secret called
MyTestSecret
from AWS Secrets Manager / Hashicorp Vault - Create it on
test-ns
namespace - Call it
test-secret
- Add few annotations and labels
- Save it as
secret.yaml
to be push to the repo safely
kubeseal-convert
supports kubeseal
raw mode, although it is an experimental feature on the SealedSecret project.
In this mode, kubeseal-convert
will fetch the secret from the external system, seal it using the raw mode, and will output to STDOUT. It's your responsibility to put it inside a SealedSecret resource.
./kubeseal-convert --raw gcpsecretsmanager 'projects/123456789/secrets/myCoolSecret/versions/1' --namespace default --name test-secret
Please read CONTRIBUTING.md for details of submitting a pull requests.
This project is licensed under the Apache License - see the LICENSE file for details.