Origin: Enable secret update to manage secret lifecycle

[aweiteka]

When I deploy an application that has a secret (a configuration file, for example), I want to be able to update the secret payload. I would like to be instructed how to deploy that update as well. Example workflow:

1. create secret

$ oc secret new mysecret config.yaml=/path/to/my/config.yaml

1. deploy application that mounts secret
2. update secret contents

$ vi /path/to/my/config.yaml

1. update secret object

$ oc secret update mysecret config.yaml=/path/to/my/config.yaml secret "mysecret" updated. To deploy the update, run "oc deploy <deploy_config> --latest" on any deployment config that references this secret.

1. User re-deploys per instruction

oc deploy <deploy_config> --latest

[brianwcook]

This is really a pain. Currently if you need to update a secret, you have to delete and then recreate it. This breaks the linkage of the secret to service accounts, breaks volume identifiers referencing the secret and generally wreaks havok on deployment configs.

[liggitt]

You should not have to delete/recreate a secret to update it. @pmorie, can you confirm?

[lbilger]

I found this ticket while searching for a way to update a secret without deleting and re-creating it (because I didn't want to lose the labels defined for the secret). If anyone is having the same problem, this workaround might help:
oc patch secret mysecret -p '{"data": {"config.yaml": "'$(base64 /path/to/my/config.yaml)'"}}'

Of course, having an oc secret update command would feel much cleaner because the user wouldn't have to know about the internal structure of the secret.

[aweiteka]

Of course, having an oc secret update command would feel much cleaner because the user wouldn't have to know about the internal structure of the secret.

@lbilger thanks for validating the use case.

I confirmed there is no workaround outside of patch. For example, oc secret new ... does not allow one to overwrite an existing secret.

Options remain:

1. implement new verb oc secret update ... per this issue
2. implement "overwrite" flag oc secret new* --overwrite ... to allow overwriting a secret

@pmorie who should this issue be assigned to?

[openshift-bot]

Issues go stale after 90d of inactivity.

Mark the issue as fresh by commenting /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
Exclude this issue from closing by commenting /lifecycle frozen.

If this issue is safe to close now please do so with /close.

/lifecycle stale

[ceagan]

I used the patch option suggested by @lbilger to get past this issue, but on my system, the base64 command automatically wraps lines, which resulted in the command giving the unhelpful message:

error: there is no need to specify a resource type as a separate argument when passing arguments in resource/name form (e.g. 'oc get resource/' instead of 'oc get resource resource/'

I was able to get past the issue by modifying the patch command given by adding -w 0 to disable line wrapping as follows:

 oc patch secret mysecret -p '{"data": {"config.yaml": "'$(base64 -w 0 /path/to/my/config.yaml)'"}}'

[openshift-bot]

Stale issues rot after 30d of inactivity.

Mark the issue as fresh by commenting /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.
Exclude this issue from closing by commenting /lifecycle frozen.

If this issue is safe to close now please do so with /close.

/lifecycle rotten
/remove-lifecycle stale

[openshift-bot]

Rotten issues close after 30d of inactivity.

Reopen the issue by commenting /reopen.
Mark the issue as fresh by commenting /remove-lifecycle rotten.
Exclude this issue from closing again by commenting /lifecycle frozen.

/close

[ThiefMaster]

How is this closed? The lack of a sane way to update secrets without going through the webinterface and manually base64 encoding it or messing with JSON/YAML on the CLI seems like a major annoyance / missing feature.

pinging @pmorie since you were mentioned a few times. dunno who you are, but hopefully someone who can make this feature happen ;)

[openshift-ci-robot]

@ThiefMaster: you can't re-open an issue/PR unless you authored it or you are assigned to it.

In response to this:

How is this closed? The lack of a sane way to update secrets without going through the webinterface and manually base64 encoding it or messing with JSON/YAML on the CLI seems like a major annoyance / missing feature.

/reopen

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.