@kubernetes/sig-cli-bugs @kubernetes/sig-auth-bugs (for thoughts)

@sethvargo: Reiterating the mentions to trigger a notification:
@kubernetes/sig-cli-bugs

@sethvargo use kubectl config view --raw you can see the complete certificate authority data

Hey @zjj2wry

Thank you - I have another issue tracking that 😄.

The point of this issue is that at best it's a bad UX; at worst it's a miseducation on pki. "REDACTED" isn't the right word here

@sethvargo If there are multiple clusters displaying certificates, the configuration will be too long, so this switch is turned off by default. But we can add an example to help use. thanks

Hey @zjj2wry

I don't personally view truncation the responsibility of the CLI... users can pipe things to a pager if they really care. That being said, I'm not concerned about the length. The issue is purely about the word choice of "REDACTED".

The term redact means:

censor or obscure (part of a text) for legal or security purposes.

The use of the term "REDACTED" in the output implies that a CA public key is remove for security when (as you've pointed out) it is removed for truncation. Truncation and redaction are fundamentally different things, and k8s is misusing the word redacted for this use case.

Not quite a bug, but I think you're right @sethvargo a better term could be used there as it is a public key, not a private key.

@kubernetes/sig-auth-feature-requests
/remove-kind bug

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

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

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

/remove-lifecycle stale

I'm not sure what I need to do here. This was marked as a feature. Do you need something more from me?

We are waiting for someone to fix this.

/remove-good-first-issue

@mikedanese I don't think this fits our definition of a good first issue: https://git.k8s.io/community/contributors/devel/help-wanted.md#good-first-issue

So I have to keep replying to the comment bot every 30 days so it doesn't get auto-closed? That feels... odd

@cblecker thanks for the education :)

@sethvargo unfortunately other issues are higher priority and no one has stepped up to fix this. The autocloser is a form of bug bankruptcy that keeps our issue load in check. The contribex special interest group is definitely open to feedback on the bot.

@sethvargo The biggest hurdle in this is that Kubernetes is using some base64 trickery to display the string REDACTED (basically setting the certificate data to the decoded bytes from REDACTED).

We can change this to TRUNCATE or TRUNCATEDCRT but not TRUNCATED (it has to be a valid base64 encoded string). I tried exploring multiple options for the text, but I couldn't find a suitable one.

Given that we already print the user tokens and other credentials this is a bit weird. Should we redact those too? Is it okay if we print the CA certificate instead of truncating it?

@ibrasho I can't help but laugh at:

but not TRUNCATED (it has to be a valid base64 encoded string)

I'm not wed to any particular name. I also have no problem displaying the entire certificate. The crux of the issue is that a CA public key is not secret or sensitive. It's a public key 😄

I agree. The issue is with the constraints imposed by how this is implemented currently.

I tried to come up with a suitable string (given the constraint) and couldn't find anything acceptable... The only suitable option that worked for me is +DATA+TRUNCATED+. 😂

I personally prefer to print the CA certificate since we are already printing user tokens and client certs that are actual secrets.

I agree. Who do we need to get in agreement that printing the full CA is the best path forward?

the data is not omitted for security purposes, but to make the output more readable. see #7007

REDACTED is misleading... it should probably be "elided" or "..."

you can run kubectl config view --raw to view full content

@liggitt that's the crux of this issue - REDACTED is misleading. However, @ibrasho pointed out that other "long" fields are still completely printed in plain text such as client certs, so I think we need to revisit the "readability" argument. What do you think?

other "long" fields are still completely printed in plain text such as client certs

they are not... client cert/key are elided in the same way for the same reason:

$ kubectl config view
apiVersion: v1
clusters:
- cluster:
    certificate-authority-data: REDACTED
    server: https://localhost:6443/
  name: local-up-cluster
contexts:
- context:
    cluster: local-up-cluster
    user: local-up-cluster
  name: local-up-cluster
current-context: local-up-cluster
kind: Config
preferences: {}
users:
- name: local-up-cluster
  user:
    client-certificate-data: REDACTED
    client-key-data: REDACTED

something like "++data+omitted++" could be better

I think we need to revisit the "readability" argument. What do you think?

If the intent of config view without --raw specified is to be readable (which it currently is), printing many extremely long fields isn't great

Hmm what about:

cluster.CertificateAuthorityData[0:8] + " (TRUNCATED)"

I'm pretty sure that would give us a valid b64 string (8+12=20%4=0) and it would subtly hint that the data isn't a secret.

Only valid characters are A-Za-z0-9+/=. And adding a prefix from the certificate only complicates things.

DATA+OMITTED is a suitable usable option. I'll submit a PR to continue the discussion there.