How can I update a secret on Kubernetes when it is generated from a file?

Question

I've created a secret using

kubectl create secret generic production-tls \
  --from-file=./tls.key \
  --from-file=./tls.crt

If I'd like to update the values - how can I do this?

score 388 · Accepted Answer · edited Apr 07 '22 at 19:21

388

This should work:

kubectl create secret generic production-tls \
--save-config \
--dry-run=client \
--from-file=./tls.key --from-file=./tls.crt \
-o yaml | \
kubectl apply -f -

edited Apr 07 '22 at 19:21

Jonathan

5,495
4
38
53

answered Aug 25 '17 at 12:17

Janos Lenart

25,074
5
73
75

14

In the latest version of k8s, you'll need to provide `--save-config` to the `kubectl create secret` in order to avoid a CLI warning. – David House Oct 20 '18 at 18:42
6

fyi, recent (Sept 2019) syntax that worked for tls secret: ```kubectl create secret tls my-domain-tls --namespace=default --key=./tls.key --cert=./tls.crt --dry-run -o yaml | kubectl apply -f -``` The certs were in plain text. – ldg Sep 12 '19 at 23:47
5

Need to use `--dry-run=client` with kubectl 1.18 or higher. – RichVel Sep 16 '20 at 10:00
This will create "kubectl.kubernetes.io/last-applied-configuration" with no encrypted values – SergkeiM May 18 '22 at 12:44
2

@Froxz, the values in a Secret are not encrypted; they are simply base64 encoded. There is no change in security from using this command. – Janos Lenart May 20 '22 at 15:09

score 115 · Answer 2 · edited Jan 25 '22 at 05:24

115

You can delete and immediately recreate the secret:

kubectl delete secret production-tls \
--ignore-not-found

kubectl create secret generic production-tls \
--from-file=./tls.key \
--from-file=./tls.crt

I put these commands in a script. The --ignore-not-found prevents getting a warning on the first run.

edited Jan 25 '22 at 05:24

Mike

1,080
1
9
25

answered Aug 25 '17 at 12:21

P.J.Meisch

18,013
6
50
66

6

what happens with pods while the secret is deleted? – Bruno Medeiros Feb 17 '19 at 15:05
7

@BrunoJCM running pods are not affected, no matter wether they get the secrets via env variables or mounted as volumes. If a pod i started in the time while there is no secret, they run into an error; therefore Janos' answer is the preferred way to go. – P.J.Meisch Feb 18 '19 at 17:55
2

Yes, I see, using `apply` makes much more sense, thanks! – Bruno Medeiros Feb 19 '19 at 05:40
This was not working for me because I forgot the `--namespace=kube-system` – Souradeep Nanda Jun 11 '19 at 05:44
2

depends on what namespace you want to add the secret to, if not _default_ than of course you have to add the namespace argument. – P.J.Meisch Jun 11 '19 at 06:42
I use this approach in CI scripts. But it produce race condition when several jobs run simultaneous and one script failed in case secret was deleted and not yet created. Be careful! – Panoptik Nov 20 '20 at 08:52
That solution is not equivalent to an update, as requested by the OP. Deleting the secret means losing all metadata in the secret, as well as any other field in the secret. – Denilson Jan 06 '23 at 16:20

Devy · Answer 3 · 2019-03-26T21:10:24.303

14

Alternatively, you can also use jq's = or |= operator to update secrets on the fly.

TLS_KEY=$(base64 < "./tls.key" | tr -d '\n')
TLS_CRT=$(base64 < "./tls.crt" | tr -d '\n')
kubectl get secrets production-tls -o json \
        | jq '.data["tls.key"] |= "$TLS_KEY"' \
        | jq '.data["tls.crt"] |= "$TLS_CRT"' \
        | kubectl apply -f -

Although it might not be as elegant or simple as the kubectl create secret generic --dry-run approach, technically, this approach is truly updating values rather than deleting/recreating them. You'll also need jq and base64 (or openssl enc -base64) commands available, tr is a commonly-available Linux utility for trimming trailing newlines.

See here for more details about jq update operator |=.

edited Mar 26 '19 at 21:10

answered Nov 16 '18 at 18:18

Devy

9,655
8
61
59

1

Can you just add `-w0` to disable line wrapping in the `base64` command? https://linux.die.net/man/1/base64 – patricknelson Dec 16 '20 at 03:51
@chunk_split no. I am using macOS, the BSD version of the base64 command doesn't have that optioin. – Devy Dec 22 '20 at 14:03
Conceptually, assigning the values to variables increases the chances of them getting leaked into a log file when someone turns debugging on with `set -x`. On a more practical level, since the jq arguments are between single quotes, the shell variables are not going to be expanded. Therefore, the final secret will have the literal characters $TLS_KEY and $TLS_CRT instead of their actual values. You would need to do something like: jq --arg TLS_KEY $TLS_KEY '.data["tls.key"] |= "$TLS_KEY"' – Denilson Jan 06 '23 at 16:30

CJ Maahs · Answer 4 · 2020-02-21T17:55:01.453

As I wasn't able to reply to Devy's answer above, which I like because it will preserve Ownership where deleting and recreating has the potential to lose any extra information in the record. I'm adding this for the newer people who may not immediately understand whey their variables aren't being interpolated.

TLS_KEY=$(base64 < "./tls.key" | tr -d '\n')
TLS_CRT=$(base64 < "./tls.crt" | tr -d '\n')
kubectl get secrets production-tls -o json \
        | jq ".data[\"tls.key\"] |= \"$TLS_KEY\"" \
        | jq ".data[\"tls.crt\"] |= \"$TLS_CRT\"" \
        | kubectl apply -f -

This lead me to attempting to use the 'patch' method of kubectl, which also seems to work.

kubectl \
        patch \
        secret \
        production-tls \
        -p "{\"data\":{\"tls.key\":\"${TLS_KEY}\",\"tls.crt\":\"${TLS_CRT}\"}}"

Thanks Devy for the answer that best met my needs.

If you use `"stringData"` instead of `"data"` you don't need to base64 encode the value. — neu242, Jul 06 '23 at 07:45

score 4 · Answer 5 · answered Apr 01 '21 at 08:16

Late to the party but still here are my inputs.

Potentially we can use both the patch or edit option.

With edit :
```
kubectl edit secrets/<SECRET_NAME> -n <NAME_SPACE>
```
- NOT the recommended way of editing the secrets.
- You should have enough permission to do the above edit.
- The value should be base64 encode by yourself and then the encoded value should be placed while editing.
With patch :
- this may help you How to update secret with "kubectl patch --type='json'"

score 3 · Answer 6 · edited Mar 31 '21 at 19:04

3

For more specific cases you might need to specify your namespace that the cert needs to be renewed and delete the old one.

For deletion of the cert

kubectl delete secret -n `namespace`

For the creation of new cert to specific namespace

kubectl create secret {your-cert-name} --key /etc/certs/{name}.com.key --cert /etc/certs/{name}.com.crt -n {namespace}

edited Mar 31 '21 at 19:04

Preetham

577
5
13

answered Nov 04 '19 at 15:06

JohnBegood

652
1
7
8

E.g.: One example `oc delete secret secret-name -n "openshift-config"`. – Eduardo Lucio Jul 01 '21 at 21:52

score 2 · Answer 7 · answered Sep 03 '20 at 08:22

Just to expand on these answers I found that adding '--ignore-not-found' to the delete helped with our CICD as it wouldn't error out if the secret didn't exist, it would just go ahead and create it:

kubectl delete secret production-tls --ignore-not-found
kubectl create secret generic production-tls --from-file=./tls.key --from-file=./tls.crt.

score 2 · Answer 8 · answered Nov 11 '22 at 07:22

2

You can use patch secret:

kubectl patch secret my-secret  --patch="{\"data\": { \"tls.key\": \"$(base64 -w0 ./tls.key)\",\"tls.crt\": \"$(base64 -w0 ./tls.crt)\"  }}"

answered Nov 11 '22 at 07:22

Maoz Zadok

4,871
3
33
43

score 1 · Answer 9 · edited Jan 26 '22 at 23:11

1

I've found a best way to do so:

kubectl create secret generic production-tls --from-file=./tls.key  --from-file=./tls.crt --dry-run=client -o yaml | kubectl apply -f -

edited Jan 26 '22 at 23:11

ewertonvsilva

1,795
1
5
15

answered Jan 25 '22 at 10:05

rauha rauha

11
1

How can I update a secret on Kubernetes when it is generated from a file?

9 Answers9

Linked