@loozhengyuan: This issue is currently awaiting triage.

If a SIG or subproject determines this is a relevant issue, they will accept it by applying the triage/accepted label and provide further guidance.

The triage/accepted label can be added by org members by writing /triage accepted in a comment.

Welcome @loozhengyuan!

It looks like this is your first PR to kubernetes/kubernetes 🎉. Please refer to our pull request process documentation to help your PR have a smooth ride to approval.

You will be prompted by a bot to use commands during the review process. Do not be afraid to follow the prompts! It is okay to experiment. Here is the bot commands documentation.

You can also check if kubernetes/kubernetes has its own contribution guidelines.

You may want to refer to our testing guide if you run into trouble with your tests not passing.

If you are having difficulty getting your pull request seen, please follow the recommended escalation practices. Also, for tips and tricks in the contribution process you may want to read the Kubernetes contributor cheat sheet. We want to make sure your contribution gets all the attention it needs!

Thank you, and welcome to Kubernetes. 😃

Hi @loozhengyuan. Thanks for your PR.

I'm waiting for a kubernetes member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

I've added a draft implementation for the PR. I still have a few failing test cases which I have yet to resolve, will be working on those.

Some things to note:

1. I've opted to mask using a fixed-length string of asterisks since it probably isn't helpful to compare the asterisks per se.
2. For now, this only works if the object is a V1Secret. I'm not sure if there are any other objects containing sensitive values, do let me know if there are others we should consider.
3. This is expected to be the new default behaviour but i'm unsure if there are use cases where we would like to know the exact diffs of the secrets. I think this is quite unlikely because (1) comparing the base64-encoded values are not that helpful and (2) we could use kubectl get or kubectl describe if we really need to compare the values for debugging.

1. I've opted to mask using a fixed-length string of asterisks since it probably isn't helpful to compare the asterisks per se.

Let me see that, because we do want diff(1) to generate a diff between old and new, so the strings need to be different somehow. I'll comment directly on the PR.

EDIT: OK I just saw, that's quite good. I'm not sure if we can improve the wording to clarify what's going on here, I can see how it could be confusing but I'm not sure yet how we could improve that phrasing.

2. For now, this only works if the object is a V1Secret. I'm not sure if there are any other objects containing sensitive values, do let me know if there are others we should consider.

I think that's fine.

3. This is expected to be the new default behaviour but i'm unsure if there are use cases where we would like to know the exact diffs of the secrets. I think this is quite unlikely because (1) comparing the base64-encoded values are not that helpful and (2) we could use kubectl get or kubectl describe if we really need to compare the values for debugging.

I think that's fine too

Thanks for working on this!

Just to provide visibility on how this PR will change the representation of diffs for V1Secret, I’ve generated a comparison of three common scenarios using the current and new implementation of kubectl diff.

Added Secret Value

$ kubectl diff -f secret.yaml
...
@@ -1,6 +1,7 @@
 apiVersion: v1
 data:
   password: c2VjcmV0
+  username: YmFyCg==
 kind: Secret
 metadata:
   annotations:

$ kubectl diff -f secret.yaml
...
@@ -1,6 +1,7 @@
 apiVersion: v1
 data:
   password: '***'
+  username: '***'
 kind: Secret
 metadata:
   annotations:

Changed Secret Value

$ kubectl diff -f secret.yaml
...
@@ -1,6 +1,6 @@
 apiVersion: v1
 data:
-  password: c2VjcmV0
+  password: MTIzCg==
   username: YmFyCg==
 kind: Secret
 metadata:

$ kubectl diff -f secret.yaml
...
@@ -1,6 +1,6 @@
 apiVersion: v1
 data:
-  password: '*** (before)'
+  password: '*** (after)'
   username: '***'
 kind: Secret
 metadata:

Removed Secret Value

$ kubectl diff -f secret.yaml
...
@@ -1,6 +1,5 @@
 apiVersion: v1
 data:
-  password: c2VjcmV0
   username: YmFyCg==
 kind: Secret
 metadata:

$ kubectl diff -f secret.yaml
...
@@ -1,6 +1,5 @@
 apiVersion: v1
 data:
-  password: '***'
   username: '***'
 kind: Secret
 metadata:

I've resolved all the remaining test cases so this should be ready for review and testing.

I'll take a look at the code, the behavior looks good to me.
/ok-to-test

/retest

I think you'll have to refactor this a little bit. I would change the "(DIffer) Diff" function so that you can do something like this:

func (d *Differ) Diff(obj Object, printer Printer) error {
        fromObject, err := d.From.Get(obj) // This Get function doesn't exist yet
        if err != nil {
          return err
        }
        toObject, err := d.To.Get(obj) // This Get function doesn't exist yet
        if err != nil {
          return err
        }

        // XXX: Mask the data here somehow

        // you might not need to have "to" and "from" to have different printers.
	if err := d.From.Print(fromObject, printer); err != nil {
		return err
	}
	if err := d.To.Print(toObject, printer); err != nil {
		return err
	}
	return nil
}

Yeah I think that looks better, i'll work on refactoring into Differ.Diff.

@loozhengyuan any update on this?

/test pull-kubernetes-e2e-kind

@apelisse and @rikatz, I've rebased the PR and made the necessary changes, ready for another review.

Thanks
/lgtm
/approve

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: apelisse, loozhengyuan

The full list of commands accepted by this bot can be found here.

The pull request process is described here

/hold

Would you mind squashing these commits? Thanks.

/label tide/merge-method-squash
@apelisse tide can do this for us :D
/retest

/hold cancel

/retest

How can I disable this feature? Sorry if I've missed it, but I checked the docs and I tried to read through this thread...

It's great that the default is secure, but I need to be able to see the diff if I want to.

@lindhe The short answer is that there is no way to disable this feature AFAIK, but you may be able to use kubectl get or kubectl describe to achieve your purpose.

This is expected to be the new default behaviour but i'm unsure if there are use cases where we would like to know the exact diffs of the secrets. I think this is quite unlikely because (1) comparing the base64-encoded values are not that helpful and (2) we could use kubectl get or kubectl describe if we really need to compare the values for debugging.

Thanks for the response!

Yeah, I'm certainly able to use kubectl to inspect the values and inspect them manually. But when it's part of a larger deployment, that's pretty tedious and when everything else works so well with diff it's kind of annoying to have a separate work flow just for Secrets.

I think comparing the base64-encoded values is plenty helpful! Mostly because it indicates to me that I'm applying the correct value (templating and automation, or high complexity in general may make it hard to know on beforehand). And I often know what the base64 encoded value is, or at least what it should start with, so it's really helpful.

I want to emphasize again that I think it's 100% the right decision to not reveal secret values by default. But I do think there's a lot to be gained by making that optional.

And there's other tooling I think we can get inspiration from:

• In helm diff, there's a --show-secrets flag that can be used instead of the default --suppress-secrets. I've had to use that many times when debugging things.
• In terraform, secret values are redacted by default in the plan printout, but using the -json flag it's revealed.
• In kubectl the secret value is redacted when running kubectl describe secret foo (with the very helpful additional information which size each field has), while the secret value is revealed using kubectl get secrets foo -o yaml.

Thanks @lindhe for the feedback, I think it's fair to add an option for that.