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

1. Build using Makefile

make build

1. [optional] Set up local env for testing

make init-dev

1. [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.