Info level logs should redact access keys

[2rs2ts]

The info-level logs can be useful but they show access keys in cleartext. Those keys should be redacted unless some debug mode is on.

[mmerrill3]

hi @2rs2ts, can you post an example of the access keys being posted (redacted of course). I'd like to know I'm looking at the right function.

[2rs2ts]

Sure thing, here's some output from stern:

kiam-server-5fdd8f777f-ckmdj kiam {"credentials.access.key":"<REDACTED>","credentials.expiration":"2019-04-15T21:15:30Z","credentials.role":"k8s/kube-system/cluster-autoscaler","level":"info","msg":"requested new credentials","time":"2019-04-15T21:00:30Z"}
kiam-server-5fdd8f777f-ckmdj kiam {"credentials.access.key":"<REDACTED>","credentials.expiration":"2019-04-15T21:15:30Z","credentials.role":"k8s/kube-system/cluster-autoscaler","generation.metadata":0,"level":"info","msg":"fetched credentials","pod.iam.role":"k8s/kube
-system/cluster-autoscaler","pod.name":"cluster-autoscaler-58575c4878-7dtdk","pod.namespace":"kube-system","pod.status.ip":"192.168.95.246","pod.status.phase":"Running","resource.version":"111389572","time":"2019-04-15T21:00:30Z"}

I manually redacted the access key from the output here

[aidansteele]

I think access key IDs should not be redacted. They are logged in plaintext in CloudTrail and logging them here is the main way we can correlate logs.

[2rs2ts]

@aidansteele that should be opt-in. Access keys are sensitive data.