Add view/update to secrets

[kriansa]

Feature request description

Currently, podman-secrets have pretty limited usage, being only useful for not exposing credentials directly at the command line of containers. Although it has gained a few niceties feature-wise, such as new built-in drivers, it hasn't changed significantly since it was introduced.

A few things I find lacking in the current design are:

1. Updating existing secrets. Currently, we have a UpdatedAt metadata, but it's effectively not used, since we can't update them, so I imagine this was planned (?)
2. Viewing existing secrets. I know that this should probably come with a more sophisticated RBAC, but I think it would make it so much easier and avoid needing to resort to ugly workarounds (e.g. finding it on the secrets storage or creating a container to show a secret)
3. Usage in podman-login

Suggest potential solution

• podman-secret-show
• podman-secret-update
• podman-login --password-secret

Have you considered any alternatives?

Yes, I can work around it, but it isn't nearly as convenient as having a built-in CLI for it.

Additional context

I apologize if this is already planned for the short or long term. I currently have no visibility of that. I have searched on the past issues but I couldn't find anything relevant on the topic.

[vrothberg]

Thanks for reaching out, @kriansa!

I enumerated your ideas to refer to them more easily.

1. I like the idea. I think we planned to have some secret create --replace similar to other commands.
2. We could make inspecting the contents optional in secrets inspect?
3. This would have a very low priority for me since there is already an elaborate credential mechanism (see https://github.com/containers/image/blob/main/docs/containers-auth.json.5.md).

@ashley-cui @containers/podman-maintainers WDYT?

[kriansa]

Thanks for the prompt response @vrothberg!

1. Ok, the most consistent with the rest of the CLI, the better.
2. Yes I'm fine with that too
3. This is fine, I don't mind login being the way it is today, the rationale for the suggestion is to get a more consistent pattern for the usage of secrets across the ecosystem, so whenever we might want to use a secret, then we should be encouraged to use the built-in mechanism rather than rolling our own. With that in place, for example, in the future when remote drivers gets implemented, a key rotation in the container registry could be done centrally (i.e. on hashicorp Vault) and the container engines would pick it up automatically. But as I said, it doesn't bother me today, I believe that viewing and updating secrets are far more important.

[grepusername]

seconding the request for secret create --replace - at present the updated field seems redundant?

[rhatdan]

Interested in opening PRs to make this happen?

[github-actions]

A friendly reminder that this issue had no activity for 30 days.