用于单向加密秘密的 Kubernetes 控制器和工具
Problem: "I can manage all my K8s config in git, except Secrets."
Solution: Encrypt your Secret into a SealedSecret, which is safe to store - even inside a public repository. The SealedSecret can be decrypted only by the controller running in the target cluster and nobody else (not even the original author) is able to obtain the original Secret from the SealedSecret.
kube-system namespace?Sealed Secrets is composed of two parts:
kubesealThe kubeseal utility uses asymmetric crypto to encrypt secrets that only the controller can decrypt.
These encrypted secrets are encoded in a SealedSecret resource, which you can see as a recipe for creating
a secret. Here is how it looks:
apiVersion: bitnami.com/v1alpha1
kind: SealedSecret
metadata:
name: mysecret
namespace: mynamespace
spec:
encryptedData:
foo: AgBy3i4OJSWK+PiTySYZZA9rO43cGDEq.....
Once unsealed this will produce a secret equivalent to this:
apiVersion: v1
kind: Secret
metadata:
name: mysecret
namespace: mynamespace
data:
foo: YmFy # <- base64 encoded "bar"
This normal kubernetes secret will appear in the cluster
after 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).
Jump to the Installation section to get up and running.
The Usage section explores in more detail how you craft SealedSecret resources.
The 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.
In 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.
To 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.
The Sprig function library is available (except for env, expandenv and getHostByName) in addition to the default Go Text Template functions.
The metadata block is copied as is (the ownerReference field will be updated unless disabled).
Other secret fields are handled individually. The type and immutable fields are copied, and the data field can be used to template complex values on the Secret. All other fields are currently ignored.
…
The controller would unseal that into something like:
apiVersion: v1
kind: Secret
metadata:
name: mysecret
namespace: mynamespace
labels:
"jenkins.io/credentials-type": usernamePassword
annotations:
"jenkins.io/credentials-description": credentials from Kubernetes
ownerReferences:
- apiVersion: bitnami.com/v1alpha1
controller: true
kind: SealedSecret
name: mysecret
uid: 5caff6a0-c9ac-11e9-881e-42010aac003e
type: kubernetes.io/dockerconfigjson
immutable: true
data:
.dockerconfigjson: ewogICJjcmVk...
As you can see, the generated Secret resource is a "dependent object" of the SealedSecret and as such
it will be updated and deleted whenever the SealedSecret object gets updated or deleted.
The key certificate (public key portion) is used for sealing secrets,
and needs to be available wherever kubeseal is going to be
used. The certificate is not secret information, although you need to
ensure you are using the correct one.
kubeseal will fetch the certificate from the controller at runtime
(requires secure access to the Kubernetes API server), which is
convenient for interactive use, but it's known to be brittle when users
have clusters with special configurations such as private GKE clusters that have
firewalls between control plane and nodes.
An alternative workflow
is to store the certificate somewhere (e.g. local disk) with
kubeseal --fetch-cert >mycert.pem,
and use it offline with kubeseal --cert mycert.pem.
The certificate is also printed to the controller log on startup.
Since v0.9.x certificates get automatically renewed every 30 days. It's good practice that you and your team
update 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.
kubeseal --cert https://your.intranet.company.com/sealed-secrets/your-cluster.cert
It also recognizes the SEALED_SECRETS_CERT env var. (pro-tip: see also direnv).
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.
SealedSecrets are from the POV of an end user a "write only" device.
The idea is that the SealedSecret can be decrypted only by the controller running in the target cluster and nobody else (not even the original author) is able to obtain the original Secret from the SealedSecret.
The user may or may not have direct access to the target cluster. More specifically, the user might or might not have access to the Secret unsealed by the controller.
There are many ways to configure RBAC on k8s, but it's quite common to forbid low-privilege users from reading Secrets. It's also common to give users one or more namespaces where they have higher privileges, which would allow them to create and read secrets (and/or create deployments that can reference those secrets).
Encrypted 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
and just push a copy of it in a namespace where they can read secrets from.
Sealed-secrets thus behaves as if each namespace had its own independent encryption key and thus once you seal a secret for a namespace, it cannot be moved in another namespace and decrypted there.
We don't technically use an independent private key for each namespace, but instead we include the namespace name during the encryption process, effectively achieving the same result.
Furthermore, 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.
That 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).
These are the possible scopes:
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/or namespace would lead to "decryption error".namespace-wide: you can freely rename the sealed secret within a given namespace.cluster-wide: the secret can be unsealed in any namespace and can be given any name.In 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.
The scope is selected with the --scope flag:
kubeseal --scope cluster-wide <secret.yaml >sealed-secret.json
It's also possible to request a scope via annotations in the input secret you pass to kubeseal:
暂无开放 Issues，或尚未同步最近议题。