bitnami-labs / sealed-secrets Goto Github PK

I'm trying to seal a docker registry secret, but when the controller unseals the secret it is always of type: Opaque.

Sample:

$ kubectl create secret docker-registry my-registry \
  --docker-server=myserver.example.com \
  --docker-username=user \
  --docker-password=password \
  [email protected] \
  --output json --dry-run | kubeseal > sealed.json
$ kubectl apply -f sealed.json
$ kubectl get secret my-registry -o yaml

apiVersion: v1
data:
  .dockerconfigjson: [snip]
kind: Secret
metadata:
  creationTimestamp: 2018-04-09T20:52:03Z
  name: my-registry
  namespace: default
  ownerReferences:
  - apiVersion: bitnami.com/v1alpha1
    controller: true
    kind: SealedSecret
    name: my-registry
    uid: db17d8cf-3c37-11e8-98fb-0a58ac1f010d
  resourceVersion: "3425531"
  selfLink: /api/v1/namespaces/default/secrets/my-registry
  uid: db1c68ac-3c37-11e8-98fb-0a58ac1f010d
type: Opaque

Expected result: The secret's type is kubernetes.io/dockerconfigjson.

Actual result: The secret type is Opaque.

See annoyances like #38 (comment)
These were fixed in newer libjsonnet, included in kubecfg >= 0.3.0

See #34. In particular:

• it makes no sense to have a missing/empty metadata.name, this should be an error
• an empty data almost certainly indicates a misunderstanding in how to use the tool (but is possibly valid), so should trigger an explanatory warning.

Getting the following error when trying to use kubeseal with EKS.

$ kubeseal --fetch-cert
panic: Error fetching certificate: services "http:sealed-secrets-controller:" is forbidden: User "system:anonymous" cannot get services/proxy in the namespace "kube-system"

I am able to interact with the cluster normally using kubectl.

$ kubectl get pods -n kube-system
NAME                                         READY     STATUS    RESTARTS   AGE
aws-node-68vfm                               1/1       Running   0          6d
aws-node-hl9ww                               1/1       Running   1          6d
aws-node-nhkwb                               1/1       Running   1          6d
fluentd-78l2j                                1/1       Running   0          6d
fluentd-kfdn4                                1/1       Running   0          6d
fluentd-wfj48                                1/1       Running   0          6d
kube-dns-7cc87d595-fbmxq                     3/3       Running   0          6d
kube-proxy-fkpsw                             1/1       Running   0          6d
kube-proxy-lbwvz                             1/1       Running   0          6d
kube-proxy-qqs2p                             1/1       Running   0          6d
sealed-secrets-controller-5bc5488bb4-79blg   1/1       Running   0          22m

i am trying to use Sealed-Secrets as part of my CI/CD flow, but it requires extra logic to run different commands depending on if the secret is already installed or not.
Ideally same command should take care of it.

See discussion during PR #73. We had to remove the schema due to upstream k8s limitations that left us with no option to keep the schema and allow an object with arbitrary keys. This issue is to track finding a workaround and/or upstream fix that allows us to have key/value objects and a CRD schema.

Running a go get github.com/bitnami-labs/sealed-secrets/cmd/kubeseal results in the following output:

# github.com/bitnami/sealed-secrets/cmd/kubeseal
./main.go:179:44: cannot use codecs (type "github.com/bitnami/sealed-secrets/vendor/k8s.io/apimachinery/pkg/runtime/serializer".CodecFactory) as type "github.com/bitnami-labs/sealed-secrets/vendor/k8s.io/apimachinery/pkg/runtime/serializer".CodecFactory in argument to v1alpha1.NewSealedSecret
./main.go:179:44: cannot use secret (type *"github.com/bitnami/sealed-secrets/vendor/k8s.io/api/core/v1".Secret) as type *"github.com/bitnami-labs/sealed-secrets/vendor/k8s.io/api/core/v1".Secret in argument to v1alpha1.NewSealedSecret
./main.go:194:33: cannot use v1alpha1.SchemeGroupVersion (type "github.com/bitnami-labs/sealed-secrets/vendor/k8s.io/apimachinery/pkg/runtime/schema".GroupVersion) as type "github.com/bitnami/sealed-secrets/vendor/k8s.io/apimachinery/pkg/runtime".GroupVersioner in argument to prettyEncoder:
	"github.com/bitnami-labs/sealed-secrets/vendor/k8s.io/apimachinery/pkg/runtime/schema".GroupVersion does not implement "github.com/bitnami/sealed-secrets/vendor/k8s.io/apimachinery/pkg/runtime".GroupVersioner (wrong type for KindForGroupVersionKinds method)
		have KindForGroupVersionKinds([]"github.com/bitnami-labs/sealed-secrets/vendor/k8s.io/apimachinery/pkg/runtime/schema".GroupVersionKind) ("github.com/bitnami-labs/sealed-secrets/vendor/k8s.io/apimachinery/pkg/runtime/schema".GroupVersionKind, bool)
		want KindForGroupVersionKinds([]"github.com/bitnami/sealed-secrets/vendor/k8s.io/apimachinery/pkg/runtime/schema".GroupVersionKind) ("github.com/bitnami/sealed-secrets/vendor/k8s.io/apimachinery/pkg/runtime/schema".GroupVersionKind, bool)
./main.go:199:28: cannot use ssecret (type *v1alpha1.SealedSecret) as type "github.com/bitnami/sealed-secrets/vendor/k8s.io/apimachinery/pkg/runtime".Object in argument to "github.com/bitnami/sealed-secrets/vendor/k8s.io/apimachinery/pkg/runtime".Encode:
	*v1alpha1.SealedSecret does not implement "github.com/bitnami/sealed-secrets/vendor/k8s.io/apimachinery/pkg/runtime".Object (wrong type for DeepCopyObject method)
		have DeepCopyObject() "github.com/bitnami-labs/sealed-secrets/vendor/k8s.io/apimachinery/pkg/runtime".Object
		want DeepCopyObject() "github.com/bitnami/sealed-secrets/vendor/k8s.io/apimachinery/pkg/runtime".Object

I am using go 1.9.3 on macOS 10.13.2. Running a git bisect over the last few recent commits while points at commit d086031bdd8657ff04ebc5f4f5d9ef1048da7015 as the first unbuildable commit.

Looks like some of the rename during the move changed some things?

The sealed-secrets-key-admin Role has resourceName instead of resourceNames in its rules so fails on kubectl create -f controller.yaml with:

error validating "controller.yaml": error validating data: found invalid field resourceName for v1beta1.PolicyRule; if you choose to ignore these errors, turn validation off with --validate=false

I don't see it in the documentation: is there a way to rotate keys in the cluster, so that more than one keypair is supported simultaneously? By the encoding being used in the secret, it doesn't seem like it's possible.

It should be possible to rotate keys, supporting multiple keys, potentially flagging Secret objects that are using an "old" key so they can be updated to a newer key. Having an expiration period, and metrics exposed for number of secret objects using old key(s) and time left for a key to expire would also be helpful to make it possible to alert based on expiring keys, similar to a capacity alert for storage.

Will you still be able to decrypt if you no longer have access to your cluster?

Hi there, this is just a general question really: have you guys considered proposing sealed secrets as a complemente of the new 1.7 encrypted secrets?

kubeseal should provide a version command for debugging. Recently hit an issue that was difficult to debug due to not knowing what version was running. Thanks

This is mostly a question, maybe a bug report. The question being: How does the controller interact with secrets already created that have an owner reference to the Sealed Secrets CRD. My reason for asking which might be a bug report, is that on multiple occasions I've had in use secrets disappear from my clusters after something bad happens to the controller, ie. loss of a node, unexpected deletion of the controller pod, etc. I'm not strictly filing this as a bug because I have zero logs from anything indicating sealed-secrets is the culprit, just a hunch.

Really need the fix in #87, hoping an official release comes down soon. Building from source adds some complication we'd prefer not to go down. Anyone have an ETA?

~/tmp$ kubectl create secret generic mysecret --dry-run --from-literal=foo=bar -o json >mysecret.json
~/tmp$ kubeseal <mysecret.json | grep namespace
    "namespace": "mnelson",
~/tmp$ kubeseal --namespace=foo <mysecret.json | grep namespace
    "namespace": "mnelson",
~/tmp$ kubeseal --namespace=toolchain-web <mysecret.json | grep namespace
    "namespace": "mnelson",

It works fine if I manually edit mysecret.json and add the namespace metadata:

~/tmp$ cat mysecret.json 
{
    "kind": "Secret",
    "apiVersion": "v1",
    "metadata": {
        "name": "mysecret",
        "creationTimestamp": null,
        "namespace": "foo"
    },
    "data": {
        "foo": "YmFy"
    }
}
~/tmp$ kubeseal <mysecret.json | grep namespace
    "namespace": "foo",

This makes the secret creation a little more fiddly, as unless I'm missing something, the namespace can't be included in the initial kubectl create command:

~/tmp$ kubectl create secret generic mysecret --dry-run --from-literal=foo=bar -o json --namespace foo | grep namespace
~/tmp$ 

Love the idea of this project, but I encountered a (user?) problem of a non-responsive terminal. On ubuntu with the v0.7.0 kubeseal-linux-amd64.

Documentation:

...
# This is the important bit:
$ kubeseal <mysecret.json >mysealedsecret.json
...

I'm trying to do this offline so I've saved the public key as a pem file.

kubeseal <secret.json >mysealedsecret.json --cert test.pem
panic: invalid configuration: no configuration has been provided

Figuring that the '<' before secret.json might not belong there(?):

kubeseal secret.json >mysealedsecret.json --cert test.pem

This leads to kubeseal not returning anything, just seemingly working in the background. I can type more text, but it doesn't do anything so I just have to close the process. mysealedsecret.json is created, but the size is 0 bytes. (I also tried kubeseal secret.json mysealedsecret.json --cert test.pem with the same result.)

What am I missing here?

We have a use case where we want to be able to append variables to the name of a secret and not sure what might be the best way to deal with it. Looking for ideas first and then can think about whether it's PR appropriate.

When we used plain secrets, we appended the name of the secret with a version because we deploy a lot of feature branches and there's potential for changes or conflicts in the secrets. That gets done automatically by our deploy mechanism, so no need to manually update branches etc and our users never get conflicts with existing secrets. In the places we used sealed-secrets, we turned that versioning off because the name is encrypted into the data values - it needs that to ensure that one cannot just copy/paste the secret data from another sealed secret into your own one in the same cluster. So now we have two slightly different systems, we'd like to start using sealed-secrets everywhere but without a way to append variables to the name we'd need to rely on users to always keep backwards compatibility in secrets across all branches of an app.

I was wondering if/how it could be possible to deal with this situation. My idea was define the name as a pattern with substitutions and allow the substitutions to be passed in with the sealed-secret, maybe as separate labels. That idea might be quite powerful but also puts more of the burden of knowing if it's really secure on the shoulders of the user, so perhaps not a great way to go.

@anguslees any thoughts on this one?

Hi everyone,

Just ran into this issue on k8s v1.9.0. This is a fresh kops instalation of k8s with RBAC enabled. I'm creating sealed secrets from an yaml file. While trying to apply the json sealed secrets file i get:

validation failure list:
spec.data in body should match '^[^A-Za-z0-9+/=]*$'

Tried with --validate=false, but i get the same result as above.
If I apply the yaml file only, it goes through (of course it's not a sealed secret anymore)

As a reference, the yaml file contents below:

apiVersion: v1
kind: Secret
metadata:
  name: test
type: Opaque
data:
  SECRET: U0VDUkVU

Kubectl version

$ kubectl version
Client Version: version.Info{Major:"1", Minor:"9", GitVersion:"v1.9.0", GitCommit:"925c127ec6b946659ad0fd596fa959be43f0cc05", GitTreeState:"clean", BuildDate:"2017-12-15T21:07:38Z", GoVersion:"go1.9.2", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"9", GitVersion:"v1.9.0", GitCommit:"925c127ec6b946659ad0fd596fa959be43f0cc05", GitTreeState:"clean", BuildDate:"2017-12-15T20:55:30Z", GoVersion:"go1.9.2", Compiler:"gc", Platform:"linux/amd64"}

Any ideas?

The idea is that the public key is available for use offline, and this enables all sorts of interesting asymmetric workflows. It's certainly possible to do all this now, but the current implementation "hides" those possibilities: kubeseal by default just re-fetches the key at runtime, requiring appropriate privileges and access.

kubeseal should have an obvious --fetch-cert option that dumps the public key to stdout - and some clear docs/examples showing how to use that file with --cert again for offline use.

The following link obtained from the instructions in the readme returns a 404. Does the release include these files?

https://github.com/bitnami/sealed-secrets/releases/download/v0.4.0/sealedsecret-crd.yaml

This looks like a very convenient way to version control secrets.

However, I question the wisdom of suggesting to users it's safe to make the resulting ciphertext public. From your README:

Encrypt your Secret into a SealedSecret, which is safe to store - even to a public repository.

mysealedsecret.json is safe to upload to github, post to twitter,

This is counter to the principle that ciphertext be restricted to the smallest possible audience, lest a weakness be later discovered in the cipher, or if the keys were to be made public.

At least, I think, it would be responsible to explain this to users and for them to then to weigh up for themselves the tradeoff of risk versus convenience with regard to their particular use-case.

As it is, it seems flippant to suggest users they can "post to twitter" the encrypted secrets (not sure why they would ever want to do this).

The Secret spec allows for non-binary data to be provided in the stringData key as a raw string, rather than base64-encoded, for convenience. Most of my secrets are just plain strings, so it'd be awesome to add support for this to kubeseal.

Currently:

• with no data key kubeseal panics:

$ cat secret-no-data.yaml
apiVersion: v1
kind: Secret
metadata:
  name: string-data-secret
  namespace: default
stringData:
  foo: baz

$ kubeseal < secret-no-data.yaml
panic: Secret.data is empty in input Secret, assuming this is an error and aborting

goroutine 1 [running]:
main.main()
	/Users/travis/gopath/src/github.com/bitnami-labs/sealed-secrets/cmd/kubeseal/main.go:233 +0x2a8

• with a data key kubeseal creates a SealedSecret that decrypts to the key-value pair foo: bar

$ cat secret.yaml
apiVersion: v1
kind: Secret
metadata:
  name: string-data-secret
  namespace: default
data:
  foo: YmFy # bar
stringData:
  foo: baz

$ kubeseal < secret.yaml | kubectl apply -f -
sealedsecret "string-data-secret" created

$ kubectl get secret string-data-secret -o jsonpath="{['data']['foo"]}" | base64 -D
bar

In both cases I would expect it to create a SealedSecret that decrypts to the key-value pair foo: baz.

Any chance of some improved documentation or an example? It's not really clear to me how this is supposed to work...

Does the annotation go on the unencrypted or encrypted secret?
How does the controller propagate the secret to other namespaces in the cluster?

I can see you guys have an integration test for it, but I haven't been able to get it working in my cluster.

v0.3.0 release fails in 1.7 cluster:

E0703 13:41:25.346224       6 reflector.go:201] github.com/bitnami/sealed-secrets/cmd/controller/controller.go:126: Failed to list *v1alpha1.SealedSecret: User "system:serviceaccount:kube-system:sealed-secrets-controller" cannot list sealedsecrets.bitnami.com at the cluster scope. (get sealedsecrets.bitnami.com)

So, I tried jsonnet to generate json from controller.jsonnet. Then kubectl create -f has error

$ jsonnet controller.jsonnet > controller.json
$ kubectl create -f controller.json 
error: unable to decode "controller.json": Object 'Kind' is missing in

cc/ @anguslees

Now we have per-key encryption, perhaps we could add a command which takes an existing sealed secret plus the details of a new individual key/value and adds/updates it as appropriate. This workflow can happen right now but requires a diff and manual merge.

I'd imagine it could work a bit like from-literal part of the kubectl create secret:
kubectl create secret generic prod-db-secret --from-literal=username=produser

I'm trying to use sealed-secret v0.3.1 on minikube v0.20.0 with OSX Sierra

I installed it using README.md instrucctions

+ release=0.3.1
++ go env GOOS
+ GOOS=darwin
++ go env GOARCH
+ GOARCH=amd64
+ wget https://github.com/bitnami/sealed-secrets/releases/download/v0.3.1/kubeseal-darwin-amd64
--2017-07-18 13:29:36--  https://github.com/bitnami/sealed-secrets/releases/download/v0.3.1/kubeseal-darwin-amd64
Resolving github.com... 192.30.253.112, 192.30.253.113
Connecting to github.com|192.30.253.112|:443... connected.
HTTP request sent, awaiting response... 302 Found
Location: https://github-production-release-asset-2e65be.s3.amazonaws.com/92702519/ee64c40c-6650-11e7-855f-ca729a8770a3?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=AKIAIWNJYAX4CSVEH53A%2F20170718%2Fus-east-1%2Fs3%2Faws4_request&X-Amz-Date=20170718T112936Z&X-Amz-Expires=300&X-Amz-Signature=4171846265a90752b458a9989910c5285a2e824d0205b9af0009b80a8a66d4d9&X-Amz-SignedHeaders=host&actor_id=0&response-content-disposition=attachment%3B%20filename%3Dkubeseal-darwin-amd64&response-content-type=application%2Foctet-stream [following]
--2017-07-18 13:29:36--  https://github-production-release-asset-2e65be.s3.amazonaws.com/92702519/ee64c40c-6650-11e7-855f-ca729a8770a3?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=AKIAIWNJYAX4CSVEH53A%2F20170718%2Fus-east-1%2Fs3%2Faws4_request&X-Amz-Date=20170718T112936Z&X-Amz-Expires=300&X-Amz-Signature=4171846265a90752b458a9989910c5285a2e824d0205b9af0009b80a8a66d4d9&X-Amz-SignedHeaders=host&actor_id=0&response-content-disposition=attachment%3B%20filename%3Dkubeseal-darwin-amd64&response-content-type=application%2Foctet-stream
Resolving github-production-release-asset-2e65be.s3.amazonaws.com... 54.231.115.11
Connecting to github-production-release-asset-2e65be.s3.amazonaws.com|54.231.115.11|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 38325968 (37M) [application/octet-stream]
Saving to: ‘kubeseal-darwin-amd64’

kubeseal-darwin-amd64                         100%[==============================================================================================>]  36.55M  8.88MB/s    in 5.4s

2017-07-18 13:29:43 (6.74 MB/s) - ‘kubeseal-darwin-amd64’ saved [38325968/38325968]

+ sudo install -m 755 kubeseal-darwin-amd64 /usr/local/bin/kubeseal
Password:
+ kubectl create -f https://github.com/bitnami/sealed-secrets/releases/download/v0.3.1/controller.yaml
deployment "sealed-secrets-controller" created
service "sealed-secrets-controller" created
thirdpartyresource "sealed-secret.bitnami.com" created
rolebinding "sealed-secrets-controller" created
role "sealed-secrets-key-admin" created
clusterrolebinding "sealed-secrets-controller" created
clusterrole "secrets-unsealer" created
serviceaccount "sealed-secrets-controller" created

I created a simple JSON file:

{
  "version": "v0.3.1"
}

Then, I encrypted it using kubeseal:

 kubeseal < file.json  > sealed-secret.json

The recently created sealed-secrets.json file renders like this:

{
  "kind": "SealedSecret",
  "apiVersion": "bitnami.com/v1alpha1",
  "metadata": {
    "namespace": "default",
    "creationTimestamp": null
  },
  "spec": {
    "data": "AgAsE+U1LXfhDDFfA/aK7+fCo6ChFV/hAxxifSSbKME3TbTp+glYK0j4G4EIHwGzsFxSXus/ERBAUpQieHLkhVOSuvWLOvuinlmyeBzDxYBvxm2ZI+jtrscPi+3sbXbtFgPB+lQTEM9dbZooDphUX/Ma5sGavTtB1FSXrqjOJjsqeHOhR2sWPEm5nbRbMUjy8iJh7A6ZN4IJ5bNcdhJnsMLdgqxxsGu2CBdlD38z5RANKhDvN65nywzH9tu2aXdrS4wwH+FQeo8/UegBMTSF6eAJPVhwCoZ9x4be9++0CvPqFruorjbR8O1MRBIqQkzRjP6RJn422VvIzCXAjijwO5cUnb2Amw3e9zU5fD7eujWeR+wVR/nTL3+3tH7nzRXMxYB2AZ89qsW4svsNdkAgK2/MlcZzkQUvQvSDjLrjxHvQrkbxLuU+gg+BTbH7NWc8wCp8VPyvw8s2ZBrcS4hEYp7L8JcggjStNWDY2vEi4zerGCe9WJEzDg9scDbhlQOTCTZYp2rryRRhZj+g2aj5GzLwRsfNEzqoFiuwLc8uE4msEMOaSIZ1lct8NgFehsrSCGwc+yeCs7Exn5rwBUDTTkNaBGVzPp7Om0MhnPBjhSq/nFaDtlJejCSOFEE3nxbplaJzEsgM5I3B6Z3VJwlAI8qHChmCGC0MuwuvOtAO8woBEV9jlXIaqoy3J891H30C1EJter5MmEB/MXYWnWKAElOhIthpWjtEJ/sFnGCnbSMOLGafrEideNkSlPukl9oxEkICteulsMTp1srqtDOHYoz/+wXzvOJP2/6DtaxjzlByBw60o0XWVDoJnrzez9vu+Tk="
  }
}

But, when I try to create the resulting resource on K8s....

kubectl create -f sealed-secret.json
The ThirdPartyResourceData "" is invalid: metadata.name: Required value: name or generateName is required

So, I added metadata.name field, like this:

... skipped ... 
 "metadata": {
    "name": "arandomname",
    "namespace": "default",
    "creationTimestamp": null
  },
... skipped ...

And finally it works.

Hi,

I have a minikube kubernetes cluster.
I installed kubeseal and yaml necesary to use kubeseal.
From my local, I was able to download the certificate (kubeseal --fetch-cert >mycert.pem)
However, when I try to run kubeseal --cert mycert.pem < mysecret.json > encrypted.json in other machine which has not configured the minikube cluster, the kubeseal sais to me that it has not the right configuration file (it spect the .kube/* files to exists).
Would be posible to use kubeseal offline without kube configuration, only with the publick key and the secret json or yaml file?

Best regards,

Juanjo.

When creating a new sealed-secret based on a existing secret.yaml labels and annotations are lost.

This is very important, as some labels and annotations are related to helm lifecycle.

Some users can create/read the sealedsecrets resource kind but they cannot list the secrets on the api server nor tail the logs of the sealed secrets controller (e.g. because of RBAC); it's currently impossible to know whether the secret has been successfully unsealed.

Possible ideas: events and/or a "status" section (like pods, deployments etc)

status:
  secret:
    created: True

(I was also wondering about the condition objects but it seems they might be going away kubernetes/kubernetes#7856)

Currently, the informer does not do a periodic resync: https://github.com/bitnami/sealed-secrets/blob/b86679e5d7cdb3c38dd730f16c20ea5a32dea225/cmd/controller/controller.go#L71

Any objection to a PR to enable this as an option? We had a used case where this would have been helpful. It looks like it eventually will resync (10 minutes) but we may want to set this explicitly.

Currently ksonnet-seal requires you to fetch the certificate manually, and currently it is only exposed in the controller logs at startup (or by reading the root Secret object directly!).

"Better" probably involves adding an HTTP-accessible endpoint that serves the certificate, and fetching it automatically at runtime in ksonnet-seal.

TPR will be deprecated in Kubernetes 1.8, replaced by CRDs.
CRDs are beta in 1.7.

We will need to migrate sealed secrets to a CRD at some point

kubeseal versionshould return the version of the kubeseal cli tool

We should use the certificates.k8s.io API to get the k8s server to sign the sealing certificate. This would allow the client to verify it has been given a valid cert and prevent potential mitm attacks.

Steps to reproduce:

• Create a sealedsecret in the cluster
• kubectl delete the secret (not the sealed one)
• kubectl delete the sealedsecret

The controller will keep trying to delete the associate secret as part of the garbage collection, but will err continuously as the secret was already deleted:

2017/09/18 09:23:56 Updating default/mysecret
2017/09/18 09:33:16 SealedSecret default/mysecret has gone, deleting Secret
2017/09/18 09:33:16 Error updating default/mysecret, will retry: secrets "mysecret" not found
2017/09/18 09:33:16 SealedSecret default/mysecret has gone, deleting Secret
2017/09/18 09:33:16 Error updating default/mysecret, will retry: secrets "mysecret" not found
2017/09/18 09:33:16 SealedSecret default/mysecret has gone, deleting Secret
2017/09/18 09:33:16 Error updating default/mysecret, will retry: secrets "mysecret" not found
2017/09/18 09:33:16 SealedSecret default/mysecret has gone, deleting Secret
2017/09/18 09:33:16 Error updating default/mysecret, will retry: secrets "mysecret" not found
2017/09/18 09:33:16 SealedSecret default/mysecret has gone, deleting Secret
2017/09/18 09:33:16 Error updating default/mysecret, will retry: secrets "mysecret" not found
2017/09/18 09:33:16 SealedSecret default/mysecret has gone, deleting Secret
2017/09/18 09:33:16 Error updating default/mysecret, giving up: secrets "mysecret" not found
E0918 09:33:16.488086       1 controller.go:162] secrets "mysecret" not found

Just found this great project today! It looks pretty much exactly what we were considering save for a few details. Would like to contribute some extras, just had a few questions first.

We were likely going to utilize sops for the main portion of it with a controller or initializer wrapped around it. In terms of differences, there's a few things I'd be interested to gain. Mostly encrypting each secret separately to make diffs meaningful and conflicts easier to resolve. KMS support and CLI editing for those with access to the key might be good too although likely separate issues.

I use Windows, and have been using the kubeseal tool by using the Linux build with WSL, but it would be nice if a native Windows binary was available.

This is a feature request for KMS support like that of sops. Extracted from #63.

1. Get key rotation for almost free.
2. For those who wish to centralise their root keys and access to KMS + IAM rather than base it off those with access to kube-system secrets.
3. KMS together with IAM users/roles still provide the access control needed to restrict decryption to the cluster, the cluster controllers, admin users.

This is probably a bit related to #44

Input file:

{
    "kind": "Secret",
    "apiVersion": "v1",
    "metadata": {
        "name": "credentials",
        "creationTimestamp": null
    },
    "data": {
        "password": "whatever",
        "username": "whatever"
    },
    "type": "Opaque"
}

Output from kubeseal:

{
  "kind": "SealedSecret",
  "apiVersion": "bitnami.com/v1alpha1",
  "metadata": {
    "name": "credentials",
    "namespace": "default",
    "creationTimestamp": null
  },
  "spec": {
    "data": <snip>
  }
}

Is there a reason why "namespace": "default" was added, though there was none in source file?

Once there is a Windows build of the CLI #85 we should create a chocolatey package to simplify the installation

We need to ensure that the controller doesn't do the wrong thing with replicas>1, since that can happen during transient events like node/partition recovery, mis-configured upgrades, etc. Replicas>1 is a desirable feature for some HA configurations.

Note that this is just about avoiding breakage. Horizontal scalability (active/active or sharding) is not included in this issue.

Note also this could either be via a lock (as is typically done with other controllers), or via careful auditing of atomic operations and race recovery (sealed-secrets-controller only has very simple side-effects).

This looks like an awesome project but there's no technical detail about the strength of the cipher or what cipher is being used.

I'd love to add this to the list of options when presenting but there's no detail and I don't want to dig through the code to find the answer to this kinda important question!

I have a SealedSecret like this

apiVersion: bitnami.com/v1alpha1
kind: SealedSecret
metadata:
  creationTimestamp: null
  name: ceph-admin
  namespace: ns
  labels:
    component: ceph-secrets
type:
  kubernetes.io/rbd
spec:
  encryptedData:
    key: 1234

But the type: kubernetes.io/rbd argument is not passed forward to the Secret object

Hi I would like to import a SealedSecret from a file. I can do this right now with kubectl apply -f, but I need to import it via the API since the kubectl binary wouldn't be available in my execution context.

In the integration tests I saw plaintext being encrypted as a new SealedSecret using a PublicKey - https://github.com/bitnami-labs/sealed-secrets/blob/master/integration/controller_test.go#L85

I would like to import a SealedSecret which was created ahead of time and dumped in a git repo. Does that API exist currently?

Thanks,

Alex

Currently, we have a custom command (like kubeseal) that has a lot of copy pasted code from this repo but we'd like to just use this as a library. Unfortunately, I quickly ran into issues as we need a newer version of the k8s client. k8s client seems to change package layout every release. Any interest in upgrading the k8s client used by sealed-secrets? I'm happy to do the work to make it happen.

To reproduce:

1. Get an existing k8s secret as a local json file
2. Run kubeseal as per the README
3. Remove the original secret from k8s and create the sealed secret

Expected result:

• The corresponding secret is created by the sealed secret controller

Actual result:

• The secret is never created, checking the logs, the controller fails with Error updating foo/foo-secrets, giving up: resourceVersion may not be set on objects to be created

Easy to work around by removing resourceVersion (and uuid, selflink, creationTimestamp) from the metadata after step 1 above.

After fixing the error mentioned in #16 I get the following error:

Error from server (Forbidden): error when creating "controller.yaml": roles.rbac.authorization.k8s.io "sealed-secrets-key-admin" is forbidden: attempt to grant extra privileges: [{[get] [] [secrets] [sealed-secrets-key] []} {[create] [] [secrets] [] []}] user=&{client  [system:authenticated] map[]} ownerrules=[] ruleResolutionErrors=[]
Error from server (Forbidden): error when creating "controller.yaml": clusterroles.rbac.authorization.k8s.io "secrets-unsealer" is forbidden: attempt to grant extra privileges: [{[get] [ksonnet.io] [sealedsecrets] [] []} {[list] [ksonnet.io] [sealedsecrets] [] []} {[watch] [ksonnet.io] [sealedsecrets] [] []} {[create] [] [secrets] [] []} {[update] [] [secrets] [] []} {[delete] [] [secrets] [] []}] user=&{client  [system:authenticated] map[]} ownerrules=[] ruleResolutionErrors=[]

I have just created a fresh cluster on azure, via acs-engine running on k8s 1.6.6 - not quite sure where the issues is.

When running on GKE, nothing other than core Kubernetes components can run in the kube-system namespace (GKE throws errors).

Most likely it should be possible to run in any namespace. It looks like kubeseal has a --namespace argument, but from brief testing it looks like this is used for the namespace of the secret, rather than for finding the sealed-secrets-controller?

@santinoncs reports:

$ kubeseal <mysecret.json >mysealedsecret.json
panic: No Auth Provider found for name "gcp"