Secrets in sonobuoy results

[santosh02iiit]

Describe the solution you'd like [A clear and concise description of what you want to happen.]

Currently sonobuoy put all the plugins configurations in definition.json. The plugin may require some secrets to be passed to it for some of its functionalities.

There are multiple files in the sonobuoy results where these secrets are being displayed as plain text. i.e., core_v1_configmaps.json, core_v1_pods.json and plugins definition.json

It will be great if we somehow provide a flag which will hide the secrets.

Anything else you would like to add: [Miscellaneous information that will assist in solving the issue.]

Environment:

• Sonobuoy version: v0.50.0
• Kubernetes version: (use kubectl version):

Client Version: version.Info{Major:"1", Minor:"21", GitVersion:"v1.21.2", GitCommit:"092fbfbf53427de67cac1e9fa54aaa09a28371d7", GitTreeState:"clean", BuildDate:"2021-06-16T12:59:11Z", GoVersion:"go1.16.5", Compiler:"gc", Platform:"windows/amd64"} Server Version: version.Info{Major:"1", Minor:"21", GitVersion:"v1.21.1", GitCommit:"5e58841cce77d4bc13713ad2b91fa0d961e69192", GitTreeState:"clean", BuildDate:"2021-05-21T23:01:33Z", GoVersion:"go1.16.4", Compiler:"gc", Platform:"linux/amd64"}

• Kubernetes installer & version:
• Cloud provider or hardware configuration:
• OS (e.g. from /etc/os-release):

[johnSchnake]

Can you elaborate what is being shown and what you'd like redacted?

The actual secret objects are skipped over deliberately for this reason; you list configmaps and pods, but those aren't secrets. If they refer to secrets, thats not the same as the actual content of the secrets, right?

I'm assuming something is being listed more verbosely than I realize, but I'd need a clear example to repro and work with.

[santosh02iiit]

Hi John,

Thanks for the reply.

We use sonobuoy for testing like below:

sonobuoy run --wait
--plugin arc-k8s-platform/platform.yaml
--plugin-env azure-arc-platform.TENANT_ID=$AZ_TENANT_ID
--plugin-env azure-arc-platform.SUBSCRIPTION_ID=$AZ_SUBSCRIPTION_ID
--plugin-env azure-arc-platform.RESOURCE_GROUP=$RESOURCE_GROUP
--plugin-env azure-arc-platform.CLUSTER_NAME=$CLUSTERNAME
--plugin-env azure-arc-platform.LOCATION=$LOCATION
--plugin-env azure-arc-platform.CLIENT_ID=$AZ_CLIENT_ID
--plugin-env azure-arc-platform.CLIENT_SECRET=$AZ_CLIENT_SECRET
--plugin-env azure-arc-platform.HELMREGISTRY=mcr.microsoft.com/azurearck8s/batch1/stable/azure-arc-k8sagents:$arc_platform_version

Here we provide AZ_CLIENT_SECRET to arc-k8s-platform plugin. Now when we get the result tar and check the files inside it then we see that there are multiple files (i.e, core_v1_configmaps.json, core_v1_pods.json and plugins definition.json) in the sonobuoy results where this secret is being displayed as plain text.

Lets us know if we can hide these kind of parameters in the result files

[johnSchnake]

Hm. So in this case you're just specifying the secret as an env var which has no expectation of privacy.

In a generic sense, how would we know this env var should be secret?

It does raise the point though that in general, Sonobuoy doesn't give you an easy to to make something secret. Its definitely doable since you can use sonobuoy gen, manually add a secret to the yaml, and then have the plugin reference that secret.

But the question would be how to make that easier and/or do it from the CLI.

Alternatively, we could potentially mitigate this by simply providing a means by which to help redact info from the resulting tarball. That could be useful for others since I do routinely try and help folks who have to spend some time sanitizing the tarball before sharing it with me (removing IPs, node names, etc).

I'll have to have a think on this; feel free to share any ideas you have on this too. Thanks for the report/suggestion.

[stale[bot]]

There has not been much activity here. We'll be closing this issue if there are no follow-ups within 15 days.