Show content of a secret

[fhopfensperger]

Summary

Currently it's not possible to view the data of a Secret in the ArgoCD Web UI, instead of the real base64 encoded values only ++++++++ is displayed. To make the values visible, annotate the secret with argocd.argoproj.io/show-secret-value: "true".

Motivation

If the secret is created by a Kubernetes controller such as a Crossplane provider and the user does not have access to the Kubernetes API, it is impossible for the user to obtain the value of the secret.

Proposal

I've already developed the functionality and it's working fine on my system. For a secret, where we want to view the data inside the WebUI & API, we need to annotate the secret with argocd.argoproj.io/show-secret-value: "true".

Example in git:

apiVersion: v1
kind: Secret
metadata:
  name: my-secret
  annotations:
    argocd.argoproj.io/show-secret-value: "true" # `TRUE, t, 1, True` is also possible
type: connection.crossplane.io/v1alpha1

Example in Argo Web-UI:

apiVersion: v1
data:
  mySecretKey: ZjE2NmUwNmUtMWU3OS00ZjE0LWI3ZWQtNDUxMzZiM2NhYjYz
kind: Secret
metadata:
  annotations:
    argocd.argoproj.io/show-secret-value: 'TRUE'
...
  name: my-secret
...
type: connection.crossplane.io/v1alpha1

Changed code in server/application/application.go

func replaceSecretValues(obj *unstructured.Unstructured) (*unstructured.Unstructured, error) {
        // start new lines
    if val, ok := obj.GetAnnotations()[v1alpha1.AnnotationShowSecretValue]; ok {
        if b, err := strconv.ParseBool(val); err == nil && b {
            return obj, nil
        }
    }
        // end new

    if obj.GetKind() == kube.SecretKind && obj.GroupVersionKind().Group == "" {
        _, obj, err := diff.HideSecretData(nil, obj)
        if err != nil {
            return nil, err
        }
        return obj, err
    }
    return obj, nil
}

If this functionality is desired, I would like to create a pull request that includes code & tests.

[jutley]

I like this idea, though I think instead of being an attribute of the secret itself, it should be tied into the RBAC permissions for the user/application. Updating many secrets across many clusters is a lot of work (and a leaky abstraction), whereas updating some ArgoCD configuration is simpler and easier.

[telmich]

That's a feature I would be looking forward to a lot. It enables non-developers to obtain information about deployed apps, albeit still doing the base64 decode, which is imho an acceptable burden.

[choover-broad]

This feature would be a huge win for us. Although I think it would be even better if:

• ArgoCD masked all secrets by default
• The UI had a button to unmask secrets with this annotation
• Argo apps had a flag to disable/enable secret unmasking globally for all secrets managed by the app
• The UI supported diffing/editing unmasked Secrets (as with ConfigMaps).

Unfortunately sometimes you just can't get around having config mixed with secrets, in which case your only choice is to put the entire config file in a K8s Secret. Making Secrets more transparent in a customizable way (so that, for example, you can reveal secrets in pre-prod but not prod) would be extremely helpful for those cases.

[crenshaw-dev]

This feature is probably possible, but maybe a bit more involved than it appears at first. I'd recommend extreme caution. We've dealt with CVEs which would have had far worse consequences if plaintext secrets were accessible via the API.

Here would be my proposal:

• Viewing plaintext secrets in the UI should be globally disabled by default.
• If anonymous mode is enabled, viewing/editing secrets should be disabled entirely.
• If insecure mode is enabled on the API server (i.e. no TLS), viewing/editing secrets should be disabled entirely.
• There should be a new secret RBAC resource which should control the ability to view plaintext secrets in the UI.
• A Secret must have the show-secret annotation for the plaintext secret to be visible in the UI.
• Plaintext secrets, when allowed, should be masked in the UI by default - you should have to click a button to make it visible.
• Plaintext secrets should not be cached in the API server in memory or in Redis.
• Plaintext secrets should never be logged, even in debug mode (existing logging might debug full manifests or object representations of manifests, so that logging would need to be audited).

[crenshaw-dev]

I think we'd also want to sit down and have a long, careful ponder about our current XSS protections. e.g. are the current CSP headers sufficient?

[endophage]

If this feature were added it would need a specific permission. There are users that I'd want to have readonly access to be able to see a service is running and check logs, but not be permitted to view any sensitive data.

[Cyben]

Hey, is there something new with that issue?

[didlawowo]

should be interesting to have a parameter for enable secret discovery in application