Awesome

kubeseal-convert

The missing part of Sealed Secrets. :closed_lock_with_key:

Motivation

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:

1. Going into AWS Secret Manager
2. Retrieve the secret who needs to be migrated
3. Create a "normal" k8s secret
4. Fill out the values on the secret
5. Run kubeseal

Just run kubeseal-convert with the secret path.

Table of Contents

• kubeseal-convert
  • Motivation
  • Table of Contents
  • Flags & Options
    • Flags
  • Supported SM Systems
    • AWS Secrets Manager
    • Hashicorp Vault
    • Azure Key Vault
    • GCP Secrets Manager
  • Build from source
    • Prerequisites
    • Building Steps
  • Examples
    • Raw Mode
  • Contributing
  • License

Flags & Options

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>

Flags

Supported SM Systems

:white_check_mark: AWS Secrets Manager
:white_check_mark: Hashicorp Vault
:white_check_mark: Azure Key Vault - Contributed by @kroonprins
:white_check_mark: Google Secrets Manager

AWS Secrets Manager

The AWS client rely on AWS local configuration variables - config file, environment variables, etc.

Hashicorp Vault

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.

Azure Key Vault

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).

GCP Secrets Manager

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.

Build from source

Prerequisites

• Go version 1.22+
• make command installed
• kubeseal command installed, and a valid communication to the Sealed Secrets controller.

Building Steps

1. Clone this repository

git clone https://github.com/EladLeev/kubeseal-convert && cd kubeseal-convert

2. Build using Makefile

make build

3. [optional] Set up local env for testing

make init-dev

4. [optional] Run the example

Examples

./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:

1. Retrieve a secret called MyTestSecret from AWS Secrets Manager / Hashicorp Vault
2. Create it on test-ns namespace
3. Call it test-secret
4. Add few annotations and labels
5. Save it as secret.yaml to be push to the repo safely

Raw Mode

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

Contributing

Please read CONTRIBUTING.md for details of submitting a pull requests.

License

This project is licensed under the Apache License - see the LICENSE file for details.