Audit error level and above logs to ensure sensitive information is not logged, mask if needed

[ritazh]

Please describe the Improvement and/or Feature Request

Audit codebase for any error level and above logs to ensure sensitive information is not logged. e.g. password, credentials, urls. If sensitive data is included, mask it so it is not exposed in the log.

NOTE: This should be a first pass as this is an on-going activity. We should look into tools we can use to catch this for every PR.

Question: What do other projects use to audit?

Scope (please mark with X where applicable)

• New Functionality [ ]
• Install [ ]
• SMI Traffic Access Policy [ ]
• SMI Traffic Specs Policy [ ]
• SMI Traffic Split Policy [ ]
• Permissive Traffic Policy [ ]
• Ingress [ ]
• Egress [ ]
• Envoy Control Plane [ ]
• CLI Tool [ ]
• Metrics [ ]
• Certificate Management [ ]
• Sidecar Injection [ ]
• Logging [X]
• Debugging [ ]
• Tests [ ]
• CI System [ ]
• Project Release [ ]

Possible use cases

[michelleN]

Need to figure out what is considered sensitive information.

[draychev]

sub issues:

• Remove log lines where xDS request/response body is logged #2309 - remove log lines where we log xDS request/response
• In log lines where CN of a cert is used - replace it with cert's SerialNumber #2311 - replace certificate CN w/ certificate SerialNumber
  • Implement GetSerialNumber from the Certificater interface for the pkg/certificate/providers/tresor component  #2312 - implement GetSerialNumber()
• Edit log statements where a Pod's IP address is logged. #2313 - replace Pod IP address with Pod UID

[saschwanbeck]

I am not a lawyer and this is not legal advice; however, I do work in information security and have privacy engineering experience as well as security event incident management experience (i.e. security log acquisition, retention, search/alerting.)

Logs can certainly reveal sensitive information, but exactly what is sensitive and shouldn't be logged should be based on a combination of existing laws and the potential harm to a natural person which may come from the information being logged, which could potentially be leaked or shared inappropriately. Considering GDPR, CCPA, LGPD, PDPA, and HIPAA (privacy laws from many geographic areas) -- the common thread is the potential harm to the natural person.

So in regards to logging information, one should always avoid logging: passwords, email addresses, IP-addresses associated with end-users (i.e. POD IP address is ok to log), individual-person health information, credit card numbers, national ID numbers, driver's license number, etc. Most of the information that a Kubernetes cluster deals with would not contain any of this sensitive information, as the cluster, pods, and containers pertain to system components and not a natural person.

The real challenge is posed by the workloads running within the containers; they are very likely to ingest and handle personally identifiable information and potentially log it inappropriately; what this data might be would depend on the specific workload and the geography where the end user resides (example: end-user IP address is PII for EU data subjects but not for US residents!) Many companies end up writing their own logging routines to help filter out the sensitive information that their business processes from their logs. An extensible logging framework could help your customers greatly by allowing them to write their own logging filters which deal exactly with the types of PHI or PII their organization is ingesting.

If in doubt, consult your info sec or legal team.

[SanyaKochhar]

Closing for now with above linked (and many more) PRs. Can reopen in the future as needed.