[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"project-5107":3},{"id":4,"name":5,"fullName":6,"owner":7,"repo":5,"description":8,"homepage":9,"htmlUrl":10,"language":11,"languages":10,"totalLinesOfCode":10,"stars":12,"forks":13,"watchers":14,"openIssues":15,"contributorsCount":16,"subscribersCount":16,"size":16,"stars1d":17,"stars7d":18,"stars30d":19,"stars90d":16,"forks30d":16,"starsTrendScore":20,"compositeScore":21,"rankGlobal":10,"rankLanguage":10,"license":22,"archived":23,"fork":23,"defaultBranch":24,"hasWiki":23,"hasPages":25,"topics":26,"createdAt":10,"pushedAt":10,"updatedAt":32,"readmeContent":33,"aiSummary":34,"trendingCount":16,"starSnapshotCount":16,"syncStatus":17,"lastSyncTime":35,"discoverSource":36},5107,"sealed-secrets","bitnami-labs\u002Fsealed-secrets","bitnami-labs","A Kubernetes controller and tool for one-way encrypted Secrets","",null,"Go",9139,774,70,68,0,2,10,60,8,79.67,"Apache License 2.0",false,"main",true,[27,28,29,30,31],"devops-workflow","encrypt-secrets","gitops","kubernetes","kubernetes-secrets","2026-06-12 04:00:24","# \"Sealed Secrets\" for Kubernetes\n\n[![](https:\u002F\u002Fimg.shields.io\u002Fbadge\u002Finstall-docs-brightgreen.svg)](#Installation)\n[![](https:\u002F\u002Fimg.shields.io\u002Fgithub\u002Frelease\u002Fbitnami-labs\u002Fsealed-secrets.svg)](https:\u002F\u002Fgithub.com\u002Fbitnami-labs\u002Fsealed-secrets\u002Freleases\u002Flatest)\n[![](https:\u002F\u002Fimg.shields.io\u002Fhomebrew\u002Fv\u002Fkubeseal)](https:\u002F\u002Fformulae.brew.sh\u002Fformula\u002Fkubeseal)\n[![Build Status](https:\u002F\u002Fgithub.com\u002Fbitnami-labs\u002Fsealed-secrets\u002Factions\u002Fworkflows\u002Fci.yml\u002Fbadge.svg)](https:\u002F\u002Fgithub.com\u002Fbitnami-labs\u002Fsealed-secrets\u002Factions\u002Fworkflows\u002Fci.yml)\n[![](https:\u002F\u002Fimg.shields.io\u002Fgithub\u002Fv\u002Frelease\u002Fbitnami-labs\u002Fsealed-secrets?include_prereleases&label=helm&sort=semver)](https:\u002F\u002Fgithub.com\u002Fbitnami-labs\u002Fsealed-secrets\u002Freleases)\n[![Download Status](https:\u002F\u002Fimg.shields.io\u002Fdocker\u002Fpulls\u002Fbitnami\u002Fsealed-secrets-controller.svg)](https:\u002F\u002Fhub.docker.com\u002Fr\u002Fbitnami\u002Fsealed-secrets-controller)\n[![Go Report Card](https:\u002F\u002Fgoreportcard.com\u002Fbadge\u002Fgithub.com\u002Fbitnami-labs\u002Fsealed-secrets)](https:\u002F\u002Fgoreportcard.com\u002Freport\u002Fgithub.com\u002Fbitnami-labs\u002Fsealed-secrets)\n![Downloads](https:\u002F\u002Fimg.shields.io\u002Fgithub\u002Fdownloads\u002Fbitnami-labs\u002Fsealed-secrets\u002Ftotal.svg)\n\n**Problem:** \"I can manage all my K8s config in git, except Secrets.\"\n\n**Solution:** Encrypt your Secret into a SealedSecret, which *is* safe\nto store - even inside a public repository. The SealedSecret can be\ndecrypted only by the controller running in the target cluster and\nnobody else (not even the original author) is able to obtain the\noriginal Secret from the SealedSecret.\n\n\u003C!-- START doctoc generated TOC please keep comment here to allow auto update -->\n\u003C!-- DON'T EDIT THIS SECTION, INSTEAD RE-RUN doctoc TO UPDATE -->\n\n\n- [Overview](#overview)\n  - [SealedSecrets as templates for secrets](#sealedsecrets-as-templates-for-secrets)\n  - [Public key \u002F Certificate](#public-key--certificate)\n  - [Scopes](#scopes)\n- [Installation](#installation)\n  - [Installation in Restricted Environments (No RBAC)](#installation-in-restricted-environments-no-rbac)\n  - [Controller](#controller)\n    - [Kustomize](#kustomize)\n    - [Helm Chart](#helm-chart)\n      - [Helm Chart on a restricted environment](#helm-chart-on-a-restricted-environment)\n  - [Kubeseal](#kubeseal)\n    - [Homebrew](#homebrew)\n    - [MacPorts](#macports)\n    - [Nixpkgs](#nixpkgs)\n    - [Linux](#linux)\n    - [Installation from source](#installation-from-source)\n- [Upgrade](#upgrade)\n  - [Supported Versions](#supported-versions)\n  - [Compatibility with Kubernetes versions](#compatibility-with-kubernetes-versions)\n- [Usage](#usage)\n  - [Managing existing secrets](#managing-existing-secrets)\n  - [Patching existing secrets](#patching-existing-secrets)\n  - [Seal secret which can skip set owner references](#seal-secret-which-can-skip-set-owner-references)\n  - [Update existing secrets](#update-existing-secrets)\n  - [Raw mode (experimental)](#raw-mode-experimental)\n  - [Validate a Sealed Secret](#validate-a-sealed-secret)\n- [Secret Rotation](#secret-rotation)\n  - [Sealing key renewal](#sealing-key-renewal)\n  - [Key registry init priority order](#key-registry-init-priority-order)\n  - [User secret rotation](#user-secret-rotation)\n  - [Early key renewal](#early-key-renewal)\n  - [Common misconceptions about key renewal](#common-misconceptions-about-key-renewal)\n  - [Manual key management (advanced)](#manual-key-management-advanced)\n  - [Re-encryption (advanced)](#re-encryption-advanced)\n- [Details (advanced)](#details-advanced)\n  - [Crypto](#crypto)\n- [Developing](#developing)\n- [FAQ](#faq)\n  - [Can I encrypt multiple secrets at once, in one YAML \u002F JSON file?](#can-i-encrypt-multiple-secrets-at-once-in-one-yaml--json-file)\n  - [Will you still be able to decrypt if you no longer have access to your cluster?](#will-you-still-be-able-to-decrypt-if-you-no-longer-have-access-to-your-cluster)\n  - [How can I do a backup of my SealedSecrets?](#how-can-i-do-a-backup-of-my-sealedsecrets)\n  - [Can I decrypt my secrets offline with a backup key?](#can-i-decrypt-my-secrets-offline-with-a-backup-key)\n  - [What flags are available for kubeseal?](#what-flags-are-available-for-kubeseal)\n  - [How do I update parts of JSON\u002FYAML\u002FTOML\u002F.. file encrypted with sealed secrets?](#how-do-i-update-parts-of-jsonyamltoml-file-encrypted-with-sealed-secrets)\n  - [Can I bring my own (pre-generated) certificates?](#can-i-bring-my-own-pre-generated-certificates)\n  - [How to use kubeseal if the controller is not running within the `kube-system` namespace?](#how-to-use-kubeseal-if-the-controller-is-not-running-within-the-kube-system-namespace)\n  - [How to verify the images?](#how-to-verify-the-images)\n  - [How to use one controller for a subset of namespaces](#how-to-use-one-controller-for-a-subset-of-namespaces)\n  - [Can I configure the Controller unseal retries?](#can-i-configure-the-controller-unseal-retries)\n  - [How to manage SealedSecrets across the cluster or specific namespaces?](#how-to-manage-sealedsecrets-across-the-cluster-or-specific-namespaces)\n- [Community](#community)\n  - [Related projects](#related-projects)\n\n\u003C!-- END doctoc generated TOC please keep comment here to allow auto update -->\n\n## Overview\n\nSealed Secrets is composed of two parts:\n\n- A cluster-side controller \u002F operator\n- A client-side utility: `kubeseal`\n\nThe `kubeseal` utility uses asymmetric crypto to encrypt secrets that only the controller can decrypt.\n\nThese encrypted secrets are encoded in a `SealedSecret` resource, which you can see as a recipe for creating\na secret. Here is how it looks:\n\n```yaml\napiVersion: bitnami.com\u002Fv1alpha1\nkind: SealedSecret\nmetadata:\n  name: mysecret\n  namespace: mynamespace\nspec:\n  encryptedData:\n    foo: AgBy3i4OJSWK+PiTySYZZA9rO43cGDEq.....\n```\n\nOnce unsealed this will produce a secret equivalent to this:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: mysecret\n  namespace: mynamespace\ndata:\n  foo: YmFy  # \u003C- base64 encoded \"bar\"\n```\n\nThis normal [kubernetes secret](https:\u002F\u002Fkubernetes.io\u002Fdocs\u002Fconcepts\u002Fconfiguration\u002Fsecret\u002F) will appear in the cluster\nafter a few seconds you can use it as you would use any secret that you would have created directly (e.g. reference it from a `Pod`).\n\nJump to the [Installation](#installation) section to get up and running.\n\nThe [Usage](#usage) section explores in more detail how you craft `SealedSecret` resources.\n\n### SealedSecrets as templates for secrets\n\nThe previous example only focused on the encrypted secret items themselves, but the relationship between a `SealedSecret` custom resource and the `Secret` it unseals into is similar in many ways (but not in all of them) to the familiar `Deployment` vs `Pod`.\n\nIn particular, the annotations and labels of a `SealedSecret` resource are not the same as the annotations of the `Secret` that gets generated out of it.\n\nTo capture this distinction, the `SealedSecret` object has a `template` section which encodes all the fields you want the controller to put in the unsealed `Secret`.\n\nThe [Sprig function library](https:\u002F\u002Fmasterminds.github.io\u002Fsprig\u002F) is available (except for `env`, `expandenv` and `getHostByName`) in addition to the default Go Text Template functions.\n\nThe `metadata` block is copied as is (the `ownerReference` field will be updated [unless disabled](#seal-secret-which-can-skip-set-owner-references)).\n\nOther secret fields are handled individually. The `type` and `immutable` fields are copied, and the `data` field can be used to [template complex values](docs\u002Fexamples\u002Fconfig-template) on the `Secret`. All other fields are currently ignored.\n\n```yaml\napiVersion: bitnami.com\u002Fv1alpha1\nkind: SealedSecret\nmetadata:\n  name: mysecret\n  namespace: mynamespace\n  annotations:\n    \"kubectl.kubernetes.io\u002Flast-applied-configuration\": ....\nspec:\n  encryptedData:\n    .dockerconfigjson: AgBy3i4OJSWK+PiTySYZZA9rO43cGDEq.....\n  template:\n    type: kubernetes.io\u002Fdockerconfigjson\n    immutable: true\n    # this is an example of labels and annotations that will be added to the output secret\n    metadata:\n      labels:\n        \"jenkins.io\u002Fcredentials-type\": usernamePassword\n      annotations:\n        \"jenkins.io\u002Fcredentials-description\": credentials from Kubernetes\n```\n\nThe controller would unseal that into something like:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: mysecret\n  namespace: mynamespace\n  labels:\n    \"jenkins.io\u002Fcredentials-type\": usernamePassword\n  annotations:\n    \"jenkins.io\u002Fcredentials-description\": credentials from Kubernetes\n  ownerReferences:\n  - apiVersion: bitnami.com\u002Fv1alpha1\n    controller: true\n    kind: SealedSecret\n    name: mysecret\n    uid: 5caff6a0-c9ac-11e9-881e-42010aac003e\ntype: kubernetes.io\u002Fdockerconfigjson\nimmutable: true\ndata:\n  .dockerconfigjson: ewogICJjcmVk...\n```\n\nAs you can see, the generated `Secret` resource is a \"dependent object\" of the `SealedSecret` and as such\nit will be updated and deleted whenever the `SealedSecret` object gets updated or deleted.\n\n### Public key \u002F Certificate\n\nThe key certificate (public key portion) is used for sealing secrets,\nand needs to be available wherever `kubeseal` is going to be\nused. The certificate is not secret information, although you need to\nensure you are using the correct one.\n\n`kubeseal` will fetch the certificate from the controller at runtime\n(requires secure access to the Kubernetes API server), which is\nconvenient for interactive use, but it's known to be brittle when users\nhave clusters with special configurations such as [private GKE clusters](docs\u002FGKE.md#private-gke-clusters) that have\nfirewalls between control plane and nodes.\n\nAn alternative workflow\nis to store the certificate somewhere (e.g. local disk) with\n`kubeseal --fetch-cert >mycert.pem`,\nand use it offline with `kubeseal --cert mycert.pem`.\nThe certificate is also printed to the controller log on startup.\n\nSince v0.9.x certificates get automatically renewed every 30 days. It's good practice that you and your team\nupdate your offline certificate periodically. To help you with that, since v0.9.2 `kubeseal` accepts URLs too. You can set up your internal automation to publish certificates somewhere you trust.\n\n```bash\nkubeseal --cert https:\u002F\u002Fyour.intranet.company.com\u002Fsealed-secrets\u002Fyour-cluster.cert\n```\n\nIt also recognizes the `SEALED_SECRETS_CERT` env var. (pro-tip: see also [direnv](https:\u002F\u002Fgithub.com\u002Fdirenv\u002Fdirenv)).\n\n> **NOTE**: we are working on providing key management mechanisms that offload the encryption to HSM based modules or managed cloud crypto solutions such as KMS.\n\n### Scopes\n\nSealedSecrets are from the POV of an end user a \"write only\" device.\n\nThe idea is that the SealedSecret can be decrypted only by the controller running in the target cluster and\nnobody else (not even the original author) is able to obtain the original Secret from the SealedSecret.\n\nThe user may or may not have direct access to the target cluster.\nMore specifically, the user might or might not have access to the Secret unsealed by the controller.\n\nThere are many ways to configure RBAC on k8s, but it's quite common to forbid low-privilege users\nfrom reading Secrets. It's also common to give users one or more namespaces where they have higher privileges,\nwhich would allow them to create and read secrets (and\u002For create deployments that can reference those secrets).\n\nEncrypted `SealedSecret` resources are designed to be safe to be looked at without gaining any knowledge about the secrets it conceals. This implies that we cannot allow users to read a SealedSecret meant for a namespace they wouldn't have access to\nand just push a copy of it in a namespace where they can read secrets from.\n\nSealed-secrets thus behaves *as if* each namespace had its own independent encryption key and thus once you\nseal a secret for a namespace, it cannot be moved in another namespace and decrypted there.\n\nWe don't technically use an independent private key for each namespace, but instead we *include* the namespace name\nduring the encryption process, effectively achieving the same result.\n\nFurthermore, namespaces are not the only level at which RBAC configurations can decide who can see which secret. In fact, it's possible that users can access a secret called `foo` in a given namespace but not any other secret in the same namespace. We cannot thus by default let users freely rename `SealedSecret` resources otherwise a malicious user would be able to decrypt any SealedSecret for that namespace by just renaming it to overwrite the one secret user does have access to. We use the same mechanism used to include the namespace in the encryption key to also include the secret name.\n\nThat said, there are many scenarios where you might not care about this level of protection. For example, the only people who have access to your clusters are either admins or they cannot read any `Secret` resource at all. You might have a use case for moving a sealed secret to other namespaces (e.g. you might not know the namespace name upfront), or you might not know the name of the secret (e.g. it could contain a unique suffix based on the hash of the contents etc).\n\nThese are the possible scopes:\n\n- `strict` (default): the secret must be sealed with exactly the same *name* and *namespace*. These attributes become *part of the encrypted data* and thus changing name and\u002For namespace would lead to \"decryption error\".\n- `namespace-wide`: you can freely *rename* the sealed secret within a given namespace.\n- `cluster-wide`: the secret can be unsealed in *any* namespace and can be given *any* name.\n\nIn contrast to the restrictions of *name* and *namespace*, secret *items* (i.e. JSON object keys like `spec.encryptedData.my-key`) can be renamed at will without losing the ability to decrypt the sealed secret.\n\nThe scope is selected with the `--scope` flag:\n\n```bash\nkubeseal --scope cluster-wide \u003Csecret.yaml >sealed-secret.json\n```\n\nIt's also possible to request a scope via annotations in the input secret you pass to `kubeseal`:\n\n- `sealedsecrets.bitnami.com\u002Fnamespace-wide: \"true\"` -> for `namespace-wide`\n- `sealedsecrets.bitnami.com\u002Fcluster-wide: \"true\"` -> for `cluster-wide`\n\nThe lack of any of such annotations means `strict` mode. If both are set, `cluster-wide` takes precedence.\n\n> NOTE: Next release will consolidate this into a single `sealedsecrets.bitnami.com\u002Fscope` annotation.\n\n## Installation\n\nSee https:\u002F\u002Fgithub.com\u002Fbitnami-labs\u002Fsealed-secrets\u002Freleases for the latest release and detailed installation instructions.\n\nCloud platform specific notes and instructions:\n\n- [GKE](docs\u002FGKE.md)\n\n### Installation in Restricted Environments (No RBAC)\n\nIn environments where you lack permissions to create cluster-wide RBAC resources (like `ClusterRoles`), you can use the **`controller-norbac.yaml`** manifest available on the Releases page.\n\nThis version is a minimal deployment that includes only the **Deployment**, **Service**, and **CustomResourceDefinition**. It intentionally omits `ServiceAccount`, `ClusterRole`, and `ClusterRoleBinding`.\n\n**Requirements:**\n1. A cluster administrator must have already installed the SealedSecret CRDs.\n2. You must have an allocated Service Account to run the deployment\n\n### Controller\n\nOnce you deploy the manifest it will create the `SealedSecret` resource\nand install the controller into `kube-system` namespace, create a service\naccount and necessary RBAC roles.\n\nAfter a few moments, the controller will start, generate a key pair,\nand be ready for operation. If it does not, check the controller logs.\n\n#### Kustomize\n\nThe official controller manifest installation mechanism is just a YAML file.\n\nIn some cases you might need to apply your own customizations, like set a custom namespace or set some env variables.\n\n`kubectl` has native support for that, see [kustomize](https:\u002F\u002Fkustomize.io\u002F).\n\n#### Helm Chart\n\nThe Sealed Secrets helm chart is now officially supported and hosted in this GitHub repo.\n\n```bash\nhelm repo add sealed-secrets https:\u002F\u002Fbitnami-labs.github.io\u002Fsealed-secrets\n```\n\n> NOTE: The versioning scheme of the helm chart differs from the versioning scheme of the sealed secrets project itself.\n\nOriginally the helm chart was maintained by the community and the first version adopted a major version of 1 while the\nsealed secrets project itself is still at major 0.\nThis is ok because the version of the helm chart itself is not meant to be necessarily the version of the app itself.\nHowever this is confusing, so our current versioning rule is:\n\n1. The `SealedSecret` controller version scheme: 0.X.Y\n2. The helm chart version scheme: 1.X.Y-rZ\n\nThere can be thus multiple revisions of the helm chart, with fixes that apply only to the helm chart without\naffecting the static YAML manifests or the controller image itself.\n\n> NOTE: The helm chart by default installs the controller with the name `sealed-secrets`, while the `kubeseal` command line interface (CLI) tries to access the controller with the name `sealed-secrets-controller`. You can explicitly pass `--controller-name` to the CLI:\n\n```bash\nkubeseal --controller-name sealed-secrets \u003Cargs>\n```\n\nAlternatively, you can set `fullnameOverride` when installing the chart to override the name. Note also that `kubeseal` assumes that the controller is installed within the `kube-system` namespace by default. So if you want to use the `kubeseal` CLI without having to pass the expected controller name and namespace you should install the Helm Chart like this:\n\n```bash\nhelm install sealed-secrets -n kube-system --set-string fullnameOverride=sealed-secrets-controller sealed-secrets\u002Fsealed-secrets\n```\n\n##### Helm Chart on a restricted environment\n\nIn some companies you might be given access only to a single namespace, not a full cluster.\n\nOne of the most restrictive environments you can encounter is:\n- A `namespace` was allocated to you with some `service account`.\n- You do not have access to the rest of the cluster, not even cluster CRDs.\n- You may not even be able to create further service accounts or roles in your namespace.\n- You are required to include resource limits in all your deployments.\n\nEven with these restrictions you can still install the sealed secrets Helm Chart, there is only one pre-requisite:\n- *The cluster must already have the sealed secrets CRDs installed*.\n\nOnce your admins installed the CRDs, if they were not there already, you can install the chart by preparing a YAML config file such as this:\n\n```shell\nserviceAccount:\n  create: false\n  name: {allocated-service-account}\nrbac:\n  create: false\n  clusterRole: false\nresources:\n  limits:\n    cpu: 150m\n    memory: 256Mi\n```\n\nNote that:\n- No service accounts are created, instead the one allocated to you will be used.\n  - `{allocated-service-account}` is the name of the `service account` you were allocated on the cluster.\n- No RBAC roles are created neither in the namespace nor the cluster.\n- Resource limits must be specified.\n  - The limits are samples that should work, but you might want to review them in your particular setup.\n\nOnce that file is ready, if you named it `config.yaml` you now can install the sealed secrets Helm Chart like this:\n\n```shell\nhelm install sealed-secrets -n {allocated-namespace} sealed-secrets\u002Fsealed-secrets --skip-crds -f config.yaml\n```\n\nWhere `{allocated-namespace}` is the name of the `namespace` you were allocated in the cluster.\n\n### Kubeseal\n\n#### Homebrew\n\nThe `kubeseal` client is also available on [homebrew](https:\u002F\u002Fformulae.brew.sh\u002Fformula\u002Fkubeseal):\n\n```bash\nbrew install kubeseal\n```\n\n#### MacPorts\n\nThe `kubeseal` client is also available on [MacPorts](https:\u002F\u002Fports.macports.org\u002Fport\u002Fkubeseal\u002Fsummary):\n\n```bash\nport install kubeseal\n```\n\n#### Nixpkgs\n\nThe `kubeseal` client is also available on [Nixpkgs](https:\u002F\u002Fsearch.nixos.org\u002Fpackages?channel=unstable&show=kubeseal&from=0&size=50&sort=relevance&type=packages&query=kubeseal): (**DISCLAIMER**: Not maintained by bitnami-labs)\n\n```bash\nnix-env -iA nixpkgs.kubeseal\n```\n\n#### Linux\n\nThe `kubeseal` client can be installed on Linux, using the below commands:\n\n```bash\nKUBESEAL_VERSION='' # Set this to, for example, KUBESEAL_VERSION='0.23.0'\ncurl -OL \"https:\u002F\u002Fgithub.com\u002Fbitnami-labs\u002Fsealed-secrets\u002Freleases\u002Fdownload\u002Fv${KUBESEAL_VERSION:?}\u002Fkubeseal-${KUBESEAL_VERSION:?}-linux-amd64.tar.gz\"\ntar -xvzf kubeseal-${KUBESEAL_VERSION:?}-linux-amd64.tar.gz kubeseal\nsudo install -m 755 kubeseal \u002Fusr\u002Flocal\u002Fbin\u002Fkubeseal\n```\n\nIf you have `curl` and `jq` installed on your machine, you can get the version dynamically this way. This can be useful for environments used in automation and such.\n\n```\n# Fetch the latest sealed-secrets version using GitHub API\nKUBESEAL_VERSION=$(curl -s https:\u002F\u002Fapi.github.com\u002Frepos\u002Fbitnami-labs\u002Fsealed-secrets\u002Ftags | jq -r '.[0].name' | cut -c 2-)\n\n# Check if the version was fetched successfully\nif [ -z \"$KUBESEAL_VERSION\" ]; then\n    echo \"Failed to fetch the latest KUBESEAL_VERSION\"\n    exit 1\nfi\n\ncurl -OL \"https:\u002F\u002Fgithub.com\u002Fbitnami-labs\u002Fsealed-secrets\u002Freleases\u002Fdownload\u002Fv${KUBESEAL_VERSION}\u002Fkubeseal-${KUBESEAL_VERSION}-linux-amd64.tar.gz\"\ntar -xvzf kubeseal-${KUBESEAL_VERSION}-linux-amd64.tar.gz kubeseal\nsudo install -m 755 kubeseal \u002Fusr\u002Flocal\u002Fbin\u002Fkubeseal\n```\n\nwhere `KUBESEAL_VERSION` is the [version tag](https:\u002F\u002Fgithub.com\u002Fbitnami-labs\u002Fsealed-secrets\u002Ftags) of the kubeseal release you want to use. For example: `v0.18.0`.\n\n#### Installation from source\n\nIf you just want the latest client tool, it can be installed into\n`$GOPATH\u002Fbin` with:\n\n```bash\ngo install github.com\u002Fbitnami-labs\u002Fsealed-secrets\u002Fcmd\u002Fkubeseal@main\n```\n\nYou can specify a release tag or a commit SHA instead of `main`.\n\nThe `go install` command will place the `kubeseal` binary at `$GOPATH\u002Fbin`:\n\n```bash\n$(go env GOPATH)\u002Fbin\u002Fkubeseal\n```\n\n## Upgrade\n\nDon't forget to check the [release notes](RELEASE-NOTES.md) for guidance about\npossible breaking changes when you upgrade the client tool\nand\u002For the controller.\n\n### Supported Versions\nCurrently, only the latest version of Sealed Secrets is supported for production environments.\n\n### Compatibility with Kubernetes versions\nThe Sealed Secrets controller ensures compatibility with different versions of Kubernetes by relying on a stable Kubernetes API. Typically, Kubernetes versions above 1.16 are considered compatible. However, we officially support the [currently recommended Kubernetes versions](https:\u002F\u002Fkubernetes.io\u002Freleases\u002F). Additionally, versions above 1.24 undergo thorough verification through our CI process with every release.\n\n## Usage\n\n```bash\n# Create a json\u002Fyaml-encoded Secret somehow:\n# (note use of `--dry-run` - this is just a local file!)\necho -n bar | kubectl create secret generic mysecret --dry-run=client --from-file=foo=\u002Fdev\u002Fstdin -o json >mysecret.json\n\n# This is the important bit:\nkubeseal -f mysecret.json -w mysealedsecret.json\n\n# At this point mysealedsecret.json is safe to upload to Github,\n# post on Twitter, etc.\n\n# Eventually:\nkubectl create -f mysealedsecret.json\n\n# Profit!\nkubectl get secret mysecret\n```\n\nNote the `SealedSecret` and `Secret` must have **the same namespace and\nname**. This is a feature to prevent other users on the same cluster\nfrom re-using your sealed secrets. See the [Scopes](#scopes) section for more info.\n\n`kubeseal` reads the namespace from the input secret, accepts an explicit `--namespace` argument, and uses\nthe `kubectl` default namespace (in that order). Any labels,\nannotations, etc on the original `Secret` are preserved, but not\nautomatically reflected in the `SealedSecret`.\n\nBy design, this scheme *does not authenticate the user*. In other\nwords, *anyone* can create a `SealedSecret` containing any `Secret`\nthey like (provided the namespace\u002Fname matches). It is up to your\nexisting config management workflow, cluster RBAC rules, etc to ensure\nthat only the intended `SealedSecret` is uploaded to the cluster. The\nonly change from existing Kubernetes is that the *contents* of the\n`Secret` are now hidden while outside the cluster.\n\n### Managing existing secrets\n\nIf you want the Sealed Secrets controller to manage an existing `Secret`, you can annotate your `Secret` with the `sealedsecrets.bitnami.com\u002Fmanaged: \"true\"` annotation. The existing `Secret` will be overwritten when unsealing a `SealedSecret` with the same name and namespace, and the `SealedSecret` will take ownership of the `Secret` (so that when the `SealedSecret` is deleted the `Secret` will also be deleted).\n\n### Patching existing secrets\n\n> New in v0.23.0\n\nThere are some use cases in which you don't want to replace the whole `Secret` but just add or modify some keys from the existing `Secret`. For this, you can annotate your `Secret` with `sealedsecrets.bitnami.com\u002Fpatch: \"true\"`. Using this annotation will make sure that secret keys, labels and annotations in the `Secret` that are not present in the `SealedSecret` won't be deleted, and those present in the `SealedSecret` will be added to the `Secret` (secret keys, labels and annotations that exist both in the `Secret` and the `SealedSecret` will be modified by the `SealedSecret`).\n\nThis annotation does not make the `SealedSecret` take ownership of the `Secret`. You can add both the `patch` and `managed` annotations to obtain the patching behavior while also taking ownership of the `Secret`.\n\n### Seal secret which can skip set owner references\n\nIf you want `SealedSecret` and the `Secret` to be independent, which mean when you delete the `SealedSecret` the `Secret` won't disappear with it, then you have to annotate that Secret with the annotation `sealedsecrets.bitnami.com\u002Fskip-set-owner-references: \"true\"` ahead of applying the Usage steps. You still may also add `sealedsecrets.bitnami.com\u002Fmanaged: \"true\"` to your `Secret` so that your secret will be updated when `SealedSecret` is updated.\n\n### Update existing secrets\n\nIf you want to add or update existing sealed secrets without having the cleartext for the other items,\nyou can just copy&paste the new encrypted data items and merge it into an existing sealed secret.\n\nYou must take care of sealing the updated items with a compatible name and namespace (see note about scopes above).\n\nYou can use the `--merge-into` command to update an existing sealed secrets if you don't want to copy&paste:\n\n```bash\necho -n bar | kubectl create secret generic mysecret --dry-run=client --from-file=foo=\u002Fdev\u002Fstdin -o json \\\n  | kubeseal > mysealedsecret.json\necho -n baz | kubectl create secret generic mysecret --dry-run=client --from-file=bar=\u002Fdev\u002Fstdin -o json \\\n  | kubeseal --merge-into mysealedsecret.json\n```\n\n### Raw mode (experimental)\n\nCreating temporary Secret with the `kubectl` command, only to throw it away once piped to `kubeseal` can\nbe a quite unfriendly user experience. We're working on an overhaul of the CLI experience. In the meantime,\nwe offer an alternative mode where kubeseal only cares about encrypting a value to stdout, and it's your responsibility to put it inside a `SealedSecret` resource (not unlike any of the other k8s resources).\n\nIt can also be useful as a building block for editor\u002FIDE integrations.\n\nThe downside is that you have to be careful to be consistent with the sealing scope, the namespace and the name.\n\nSee [Scopes](#scopes)\n\n`strict` scope (default):\n\n```console\n$ echo -n foo | kubeseal --raw --namespace bar --name mysecret\nAgBChHUWLMx...\n```\n\n`namespace-wide` scope:\n\n```console\n$ echo -n foo | kubeseal --raw --namespace bar --scope namespace-wide\nAgAbbFNkM54...\n```\nInclude the `sealedsecrets.bitnami.com\u002Fnamespace-wide` annotation in the `SealedSecret`\n```yaml\nmetadata:\n  annotations:\n    sealedsecrets.bitnami.com\u002Fnamespace-wide: \"true\"\n```\n\n`cluster-wide` scope:\n\n```console\n$ echo -n foo | kubeseal --raw --scope cluster-wide\nAgAjLKpIYV+...\n```\nInclude the `sealedsecrets.bitnami.com\u002Fcluster-wide` annotation in the `SealedSecret`\n```yaml\nmetadata:\n  annotations:\n    sealedsecrets.bitnami.com\u002Fcluster-wide: \"true\"\n```\n\n### Validate a Sealed Secret\n\nIf you want to validate an existing sealed secret, `kubeseal` has the flag `--validate` to help you.\n\nGiving a file named `sealed-secrets.yaml` containing the following sealed secret:\n\n```yaml\napiVersion: bitnami.com\u002Fv1alpha1\nkind: SealedSecret\nmetadata:\n  name: mysecret\n  namespace: mynamespace\nspec:\n  encryptedData:\n    foo: AgBy3i4OJSWK+PiTySYZZA9rO43cGDEq.....\n```\n\nYou can validate if the sealed secret was properly created or not:\n\n```console\n$ cat sealed-secrets.yaml | kubeseal --validate\n```\n\nIn case of an invalid sealed secret, `kubeseal` will show:\n\n```console\n$ cat sealed-secrets.yaml | kubeseal --validate\nerror: unable to decrypt sealed secret\n```\n\n## Secret Rotation\n\nYou should always rotate your secrets. But since your secrets are encrypted with another secret,\nyou need to understand how these two layers relate to take the right decisions.\n\nTL;DR:\n\n> If a *sealing* private key is compromised, you need to follow the instructions below in \"Early key renewal\"\n> section before rotating any of your actual secret values.\n>\n> SealedSecret key renewal and re-encryption features are **not a substitute** for periodical rotation of your actual secret values.\n\n### Sealing key renewal\n\nSealing keys are automatically renewed every 30 days. Which means a new sealing key is created and appended to the set of active sealing keys the controller can use to unseal `SealedSecret` resources.\n\nThe most recently created sealing key is the one used to seal new secrets when you use `kubeseal` and it's the one whose certificate is downloaded when you use `kubeseal --fetch-cert`.\n\nThe renewal time of 30 days is a reasonable default, but it can be tweaked as needed\nwith the `--key-renew-period=\u003Cvalue>` flag for the command in the pod template of the `SealedSecret` controller. The `value` field can be given as golang\nduration flag (eg: `720h30m`). Assuming that you've installed Sealed Secrets into the `kube-system` namespace, use the following command to edit the Deployment controller, and add the `--key-renew-period` parameter. Once you close your text editor, and the Deployment controller has been modified, a new Pod will be automatically created to replace the old Pod.\n\n```\nkubectl edit deployment\u002Fsealed-secrets-controller --namespace=kube-system\n```\n\nA value of `0` will deactivate automatic key renewal. Of course, you may have a valid use case for deactivating automatic sealing key renewal but experience has shown that new users often tend to jump to conclusions that they want control over key renewal, before fully understanding how sealed secrets work. Read more about this in the [common misconceptions](#common-misconceptions-about-key-renewal) section below.\n\n> Unfortunately, you cannot use e.g. \"d\" as a unit for days because that's not supported by the Go stdlib. Instead of hitting your face with a palm, take this as an opportunity to meditate on the [falsehoods programmers believe about time](https:\u002F\u002Finfiniteundo.com\u002Fpost\u002F25326999628\u002Ffalsehoods-programmers-believe-about-time).\n\nA common misunderstanding is that key renewal is often thought of as a form of key rotation, where the old key is not only obsolete but actually bad and that you thus want to get rid of it.\nIt doesn't help that this feature has been historically called \"key rotation\", which can add to the confusion.\n\nSealed secrets are not automatically rotated and old keys are not deleted\nwhen new keys are generated. Old `SealedSecret` resources can be still decrypted (that's because old sealing keys are not deleted).\n\n### Key registry init priority order\n\nWhen the controller starts, it will initialize the key registry. The most recent key is used to seal secrets. By default, this certificate is chosen based on the NotBefore attribute of the certificate. If you want to change the priority order of the keys in the registry, you can use the `--key-order-priority` flag. \n\nThe `--key-order-priority` flag accepts the following values:\n- `CertNotBefore`: (default) The key registry will be ordered based on the NotBefore attribute of the key certificate.\n- `SecretCreationTimestamp`: The key registry will be ordered based on the creation timestamp of the secret.\n\nThis flag influences the public key used to encrypt secrets and the certificate retrieved by `kubeseal --fetch-cert`. \n\n\n\n### User secret rotation\n\nThe *sealing key* renewal and SealedSecret rotation are **not a substitute** for rotating your actual secrets.\n\nA core value proposition of this tool is:\n\n> Encrypt your Secret into a SealedSecret, which *is* safe to store - even inside a public repository.\n\nIf you store anything in a version control storage, and in a public one in particular, you must assume\nyou cannot ever delete that information.\n\n*If* a sealing key somehow leaks out of the cluster you must consider all your `SealedSecret` resources\nencrypted with that key as compromised. No amount of sealing key rotation in the cluster or even re-encryption of existing SealedSecrets files can change that.\n\nThe best practice is to periodically rotate all your actual secrets (e.g. change the password) **and** craft new\n`SealedSecret` resources with those new secrets.\n\nBut if the `SealedSecret` controller was not renewing the *sealing key* that rotation would be moot,\nsince the attacker could just decrypt the new secrets as well. Thus, you need to do both: periodically renew the sealing key and rotate your actual secrets!\n\n### Early key renewal\n\nIf you know or suspect a *sealing key* has been compromised you should renew the key ASAP before you\nstart sealing your new rotated secrets, otherwise you'll be giving attackers access to your new secrets as well.\n\nA key can be generated early by passing the current timestamp to the controller into a flag called `--key-cutoff-time` or an env var called `SEALED_SECRETS_KEY_CUTOFF_TIME`. The expected format is RFC1123, you can generate it with the `date -R` unix command.\n\n### Common misconceptions about key renewal\n\nSealed secrets sealing keys are not access control keys (e.g. a password). They are more like the GPG key you might use to read encrypted mail sent to you. Let's continue with the email analogy for a bit:\n\nImagine you have reasons to believe your private GPG key might have been compromised. You'd have more to lose than to gain if the first thing you do is just delete your private key. All the previous emails sent with that key are no longer accessible to you (unless you have a decrypted copy of those emails), nor are new emails sent by your friends whom you have not yet managed to tell to use the new key.\n\nSure, the content of those encrypted emails is not secure, as an attacker might now be able to decrypt them, but what's done is done. Your sudden loss of the ability to read those emails surely doesn't undo the damage. If anything, it's worse because you no longer know for sure what secret the attacker got to know. What you really want to do is to make sure that your friend stops using your old key and that from now on all further communication is encrypted with a new key pair (i.e. your friend must know about that new key).\n\nThe same logic applies to SealedSecrets. The ultimate goal is to secure your actual \"user\" secrets. The \"sealing\" secrets are just a mechanism, an \"envelope\". If a secret is leaked there is no going back, what's done is done.\n\nYou first need to ensure that new secrets don't get encrypted with that old compromised key (in the email analogy above that's: create a new key pair and give all your friends your new public key).\n\nThe second logical step is to neutralize the damage, which depends on the nature of the secret. A simple example is a database password: if you accidentally leak your database password, the thing you're supposed to do is simply to change your database password (on the database; and revoke the old one!) *and* update the `SealedSecret` resource with the new password (i.e. running `kubeseal` again).\n\nBoth steps are described in the previous sections, albeit in a less verbose way. There is no shame in reading them again, now that you have a more in-depth grasp of the underlying rationale.\n\n### Manual key management (advanced)\n\nThe `SealedSecret` controller and the associated workflow are designed to keep old sealing keys around and periodically add new ones. You should not delete old keys unless you know what you're doing.\n\nThat said, if you want you can manually manage (create, move, delete) *sealing keys*. They are just normal k8s secrets living in the same namespace where the `SealedSecret` controller lives (usually `kube-system`, but it's configurable).\n\nThere are advanced use cases that you can address by creative management of the sealing keys.\nFor example, you can share the same sealing key among a few clusters so that you can apply exactly the same sealed secret in multiple clusters.\nSince sealing keys are just normal k8s secrets you can even use sealed secrets themselves and use a GitOps workflow to manage your sealing keys (useful when you want to share the same key among different clusters)!\n\nLabeling a *sealing key* secret with anything other than `active` effectively deletes\nthe key from the `SealedSecret` controller, but it is still available in k8s for\nmanual encryption\u002Fdecryption if need be.\n\n**NOTE** `SealedSecret` controller currently does not automatically pick up manually created, deleted or relabeled sealing keys. An admin must restart the controller before the effect will apply.\n\n### Re-encryption (advanced)\n\nBefore you can get rid of some old sealing keys you need to re-encrypt your SealedSecrets with the latest private key.\n\n```bash\nkubeseal --re-encrypt \u003Cmy_sealed_secret.json >tmp.json \\\n  && mv tmp.json my_sealed_secret.json\n```\n\nThe invocation above will produce a new sealed secret file freshly encrypted with\nthe latest key, without making the secrets leave the cluster to the client. You can then save that file\nin your version control system (`kubeseal --re-encrypt` doesn't update the in-cluster object).\n\nCurrently, old keys are not garbage collected automatically.\n\nIt's a good idea to periodically re-encrypt your SealedSecrets. But as mentioned above, don't lull yourself in a false sense of security: you must assume the old version of the `SealedSecret` resource (the one encrypted with a key you think of as dead) is still potentially around and accessible to attackers. I.e. re-encryption is not a substitute for periodically rotating your actual secrets.\n\n## Details (advanced)\n\nThis controller adds a new `SealedSecret` custom resource. The\ninteresting part of a `SealedSecret` is a base64-encoded\nasymmetrically encrypted `Secret`.\n\nThe controller maintains a set of private\u002Fpublic key pairs as kubernetes\nsecrets. Keys are labeled with `sealedsecrets.bitnami.com\u002Fsealed-secrets-key`\nand identified in the label as either `active` or `compromised`. On startup,\nThe sealed secrets controller will...\n\n1. Search for these keys and add them to its local store if they are\nlabeled as active.\n2. Create a new key\n3. Start the key rotation cycle\n\n### Crypto\n\nMore details about crypto can be found [here](docs\u002Fdeveloper\u002Fcrypto.md).\n\n## Developing\n\nDeveloping guidelines can be found [in the Developer Guide](docs\u002Fdeveloper\u002FREADME.md).\n\n## FAQ\n\n### Can I encrypt multiple secrets at once, in one YAML \u002F JSON file?\n\nYes, you can! Drop as many secrets as you like in one file. Make sure to separate them via `---` for YAML and as extra, single objects in JSON.\n\n### Will you still be able to decrypt if you no longer have access to your cluster?\n\nNo, the private keys are only stored in the Secret managed by the controller (unless you have some other backup of your k8s objects). There are no backdoors - without that private key used to encrypt a given SealedSecrets, you can't decrypt it. If you can't get to the Secrets with the encryption keys, and you also can't get to the decrypted versions of your Secrets live in the cluster, then you will need to regenerate new passwords for everything, seal them again with a new sealing key, etc.\n\n### How can I do a backup of my SealedSecrets?\n\nIf you do want to make a backup of the encryption private keys, it's easy to do from an account with suitable access:\n\n```bash\nkubectl get secret -n kube-system -l sealedsecrets.bitnami.com\u002Fsealed-secrets-key -o yaml >main.key\n\necho \"---\" >> main.key\nkubectl get secret -n kube-system sealed-secrets-key -o yaml >>main.key\n```\n\n> NOTE: You need the second statement only if you ever installed sealed-secrets older than version 0.9.x on your cluster.\n\n> NOTE: This file will contain the controller's public + private keys and should be kept omg-safe!\n\n> NOTE: After sealing key renewal you should recreate your backup. Otherwise, your backup won't be able to decrypt new sealed secrets.\n\nTo restore from a backup after some disaster, just put that secrets back before starting the controller - or if the controller was already started, replace the newly-created secrets and restart the controller:\n\n* For Helm deployment:\n    ```bash\n    kubectl apply -f main.key\n    kubectl delete pod -n kube-system -l app.kubernetes.io\u002Fname=sealed-secrets\n    ```\n\n* For deployment via `controller.yaml` manifest\n    ```bash\n    kubectl apply -f main.key\n    kubectl delete pod -n kube-system -l name=sealed-secrets-controller\n    ```\n\n### Can I decrypt my secrets offline with a backup key?\n\nWhile treating sealed-secrets as long term storage system for secrets is not the recommended use case, some people\ndo have a legitimate requirement for being able to recover secrets when the k8s cluster is down and restoring a backup into a new `SealedSecret` controller deployment is not practical.\n\nIf you have backed up one or more of your private keys (see previous question), you can use the `kubeseal --recovery-unseal --recovery-private-key file1.key,file2.key,...` command to decrypt a sealed secrets file.\n\n### What flags are available for kubeseal?\n\nYou can check the flags available using `kubeseal --help`.\n\n### How do I update parts of JSON\u002FYAML\u002FTOML\u002F.. file encrypted with sealed secrets?\n\nA kubernetes `Secret` resource contains multiple items, basically a flat map of key\u002Fvalue pairs.\nSealedSecrets operate at that level, and does not care what you put in the values. In other words\nit cannot make sense of any structured configuration file you might have put in a secret and thus\ncannot help you update individual fields in it.\n\nSince this is a common problem, especially when dealing with legacy applications, we do offer an [example](docs\u002Fexamples\u002Fconfig-template) of a possible workaround.\n\n### Can I bring my own (pre-generated) certificates?\n\nYes, you can provide the controller with your own certificates, and it will consume them.\nPlease check [here](docs\u002Fbring-your-own-certificates.md) for a workaround.\n\n### How to use kubeseal if the controller is not running within the `kube-system` namespace?\n\nIf you installed the controller in a different namespace than the default `kube-system`, you need to provide this namespace\nto the `kubeseal` commandline tool. There are two options:\n\n1. You can specify the namespace via the command line option `--controller-namespace \u003Cnamespace>`:\n\n  ```bash\nkubeseal --controller-namespace sealed-secrets \u003Cmysecret.json >mysealedsecret.json\n```\n\n2. Via the environment variable `SEALED_SECRETS_CONTROLLER_NAMESPACE`:\n\n  ```bash\nexport SEALED_SECRETS_CONTROLLER_NAMESPACE=sealed-secrets\nkubeseal \u003Cmysecret.json >mysealedsecret.json\n```\n\n### How to verify the images?\n\nOur images are being signed using [cosign](https:\u002F\u002Fgithub.com\u002Fsigstore\u002Fcosign). The signatures have been saved in our [GitHub Container Registry](https:\u002F\u002Fghcr.io\u002Fbitnami-labs\u002Fsealed-secrets-controller\u002Fsigns).\n\n> Images up to and including v0.20.2 were signed using Cosign v1. Newer images are signed with Cosign v2.\n\nIt is pretty simple to verify the images:\n\n```bash\n# export the COSIGN_VARIABLE setting up the GitHub container registry signs path\nexport COSIGN_REPOSITORY=ghcr.io\u002Fbitnami-labs\u002Fsealed-secrets-controller\u002Fsigns\n\n# verify the image uploaded in GHCR\ncosign verify --key .github\u002Fworkflows\u002Fcosign.pub ghcr.io\u002Fbitnami-labs\u002Fsealed-secrets-controller:latest\n\n# verify the image uploaded in Dockerhub\ncosign verify --key .github\u002Fworkflows\u002Fcosign.pub docker.io\u002Fbitnami\u002Fsealed-secrets-controller:latest\n```\n\n### How to use one controller for a subset of namespaces\n\nIf you want to use one controller for more than one namespace, but not all namespaces, you can provide additional namespaces using the command line flag `--additional-namespaces=\u003Cnamespace1>,\u003Cnamespace2>,\u003C...>`. Make sure you provide appropriate roles and rolebindings in the target namespaces, so the controller can manage the secrets in there.\n\n### Can I configure the Controller unseal retries?\n\nThe answer is yes, you can configure the number of retries in your controller using the flag `--max-unseal-retries`. This flag allows you to configure the number of maximum retries to unseal your Sealed Secrets.\n\n### How to manage SealedSecrets across the cluster or specific namespaces?\n\nBy default, the controller watches for `SealedSecret` resources across **all namespaces** using the `--all-namespaces` flag (which defaults to `true`).\n\nIf you need to restrict the controller's scope, you have two options:\n- **Watch a subset of namespaces:** Use the `--additional-namespaces=\u003Cns1>,\u003Cns2>` flag to provide a comma-separated list of namespaces for the controller to manage.\n- **Watch only the local namespace:** Set `--all-namespaces=false` (or the environment variable `SEALED_SECRETS_ALL_NAMESPACES=false`). This is useful for multi-tenant clusters where you want isolated controllers with independent sealing keys in each namespace.\n\n## Community\n\n- [#sealed-secrets on Kubernetes Slack](https:\u002F\u002Fkubernetes.slack.com\u002Fmessages\u002Fsealed-secrets)\n\nClick [here](http:\u002F\u002Fslack.k8s.io) to sign up to the Kubernetes Slack org.\n\n### Related projects\n\n- `kseal` A Kubeseal Companion: [https:\u002F\u002Fgithub.com\u002Feznix86\u002Fkseal](https:\u002F\u002Fgithub.com\u002Feznix86\u002Fkseal)\n- `kubeseal-convert`: [https:\u002F\u002Fgithub.com\u002FEladLeev\u002Fkubeseal-convert](https:\u002F\u002Fgithub.com\u002FEladLeev\u002Fkubeseal-convert)\n- Visual Studio Code extension: [https:\u002F\u002Fmarketplace.visualstudio.com\u002Fitems?itemName=codecontemplator.kubeseal](https:\u002F\u002Fmarketplace.visualstudio.com\u002Fitems?itemName=codecontemplator.kubeseal)\n- WebSeal: generates secrets in the browser: [https:\u002F\u002Fsocialgouv.github.io\u002Fwebseal](https:\u002F\u002Fsocialgouv.github.io\u002Fwebseal)\n- HybridEncrypt TypeScript implementation: [https:\u002F\u002Fgithub.com\u002FSocialGouv\u002Faes-gcm-rsa-oaep](https:\u002F\u002Fgithub.com\u002FSocialGouv\u002Faes-gcm-rsa-oaep)\n- [DEPRACATED] Sealed Secrets Operator: [https:\u002F\u002Fgithub.com\u002Fdisposab1e\u002Fsealed-secrets-operator-helm](https:\u002F\u002Fgithub.com\u002Fdisposab1e\u002Fsealed-secrets-operator-helm)\n","Sealed Secrets 是一个用于 Kubernetes 的控制器和工具，可以将敏感信息加密成只能由目标集群解密的 SealedSecret。其核心功能是通过公钥\u002F证书机制实现对 Secret 的单向加密，确保即使在公开仓库中存储这些加密后的 Secret 也是安全的，只有目标集群中的控制器能够解密它们。该工具特别适用于需要遵循 GitOps 流程但又必须保证敏感数据（如密码、API 密钥等）安全性的场景。使用 Go 语言开发，并且支持多种安装方式包括 Helm Chart 和 Kustomize 等，方便集成到现有的 CI\u002FCD 流程中。","2026-06-11 03:02:33","top_language"]