Components logs sanitization

[fabriziopandini]

User Story

As a user, I would like Cluster API adopts the same logs sanitization rules used in Kubernetes

Detailed Description

Wtih KEP-1753: Kubernetes system components logs sanitization Kubernetes is introducing a set of sanitization rules leveraging on klog and golang tags.

Those tags will be used for ensuring this data will not be written to logs by Kubernetes system components.

List of datapolicy tags available:

• security-key - for TLS certificate keys. Keywords: key, cert, pem
• token - for HTTP authorization tokens. Keywords: token, secret, header, auth
• password - anything passwordlike. Keywords: password

Anything else you would like to add:

/kind feature
/sig instrumentation security

[vincepri]

/milestone v0.4.0
/help
/priority important-longterm

[k8s-ci-robot]

@vincepri:
This request has been marked as needing help from a contributor.

Please ensure the request meets the requirements listed here.

If this request no longer meets these requirements, the label can be removed
by commenting with the /remove-help command.

In response to this:

/milestone v0.4.0
/help
/priority important-longterm

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[fabriziopandini]

Quoting from the proposal the implementation plan

Alpha (1.20)

• All well-known places which contain sensitive data have been tagged.
• All external well-known types are handled by the GlobalDatapolicyMapping function.
• It is possible to turn on logs sanitization for all Kubernetes components including API Server, Scheduler, Controller manager and kubelet using --logging-sanitization flag.
  Beta (1.21)
• Performance overhead related to enabling dynamic logs sanitization has been reduced to 50% compared to time spent in - -- klog library functions with this feature disabled. This should be verified using Kubernetes scalability tests.
  GA (1.22)
• Logs sanitization is enabled by default.

I think we should postpone this after 1.21, when performance issues are addressed

[vincepri]

/milestone Next

[fejta-bot]

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-contributor-experience at kubernetes/community.
/lifecycle stale

[fejta-bot]

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.

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

Send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle rotten

[sbueringer]

/remove-lifecycle rotten

[k8s-triage-robot]

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-contributor-experience at kubernetes/community.
/lifecycle stale

[vincepri]

/lifecycle frozen

[sbueringer]

I think this PR #6072 could provide us the sanitizing functionality in logging, so that we only have to go over the structs and tag them (if there are any)

[sbueringer]

/assign

I'll re-evaluate once when/if the JSON log format PR is merged.

[sbueringer]

The upstream dynamic log sanitization filter has been deprecated and will be removed (Deprecation PR).

The tags are still used and there is a KEP for static analysis: https://github.com/kubernetes/enhancements/tree/master/keps/sig-security/1933-secret-logging-static-analysis

It sounds interesting, but we have to test if it makes sense for us.

[fabriziopandini]

given that in CAPI we are storing all sensitive info in secrets, I'm leaning towards closing this issue (decorating types and running the static analysis won't provide a great signal).

[sbueringer]

The static analysis is pretty fancy. I would keep the issue for now, I just want to try the linter at some point.
(and then evaluate if it makes sense for us nor not)

[sbueringer]

I took another look. The tool itself looks interesting, but I couldn't get it to work. It also looks like upstream Kubernetes has issues with Go 1.19 and levee and requires fixes in a Go lib to get it to work again.

I even couldn't get it to work with Go 1.18 locally.

So overall I agree, given that almost all our secrets are in Secrets and we have a lot of untyped JSON patches in which secrets basically can't be detected I would close this issue as the benefit doesn't outweigh the effort to get it to work and to maintain it over time.

/close

[k8s-ci-robot]

@sbueringer: Closing this issue.

In response to this:

I took another look. The tool itself looks interesting, but I couldn't get it to work. It also looks like upstream Kubernetes has issues with Go 1.19 and levee and requires fixes in a Go lib to get it to work again.

I even couldn't get it to work with Go 1.18 locally.

So overall I agree, given that almost all our secrets are in Secrets and we have a lot of untyped JSON patches in which secrets basically can't be detected I would close this issue as the benefit doesn't outweigh the effort to get it to work and to maintain it over time.

/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.