-
Notifications
You must be signed in to change notification settings - Fork 1.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
An example is missed, related to eventRecordQPS #1104
Comments
I don't know what is an appropriate level, after googling, I think eventRecordQPS should be set to 0. |
@winkee01 Thanks for reporting. The content of
It depends on your environment and business. |
@winkee01 You should avoid 0 unless you're using the deprecated This is confusing because when using the deprecated command line option, https://github.com/kubernetes/kubernetes/blob/master/cmd/kubelet/app/options/options.go https://github.com/kubernetes/kubernetes/blob/master/pkg/kubelet/apis/config/v1beta1/defaults.go |
@mozillazg Note that these AFAICT, the tests are looking for a 0 in a deprecated flag ( For the deprecated command line flag, 0 means use the default value of 5, whereas in the config file, the default value if the field is missing is 5, but an explicit value of 0 disables rate limiting, which is precisely what this rule is supposed to prevent. |
Hey @joebowbeer !
I read the CIS benchmark the other way around - losing security events due to rate-limiting is the main issue the CIS benchmark wants to prevent here, as per their introductory line: "Security relevant information should be logged", and the rationale "it is important to not restrict event creation". Rate-limiting will indeed prevent events from being created (if there's too many of them), so rate-limiting should be disabled. The discussion about kubelet denial of service is an important caveat, but ought to be addressed by scaling up the relevant logging infrastructure rather than by setting a rate-limit here. Does that make sense to you as well? |
@Pluies I wrote more at awslabs/amazon-eks-ami#391 where this comment aligns with my interpretation of the original intent. The original recommendation was to set Setting --event-qps to 0 was equivalent to not setting it at all. Both cases defaulted to 5 qps, which according to some articles is appropriate for 30 pods, but YMMV. Then the flag was deprecated and the CIS Benchmark recommendation (and kube-bench) became twisted to check that either the eventRecordQPS=0 is an explicit override to disable rate limiting, whereas omitting this field defaults to 5, which is equivalent to setting --event-qps to 0. I can't claim that disabling rate limiting is necessarily wrong, but it is obvious from the source code and history of changes that disabling all rate limiting is not the intent of the recommendation, and it should not become the new effective default for a cluster. |
in
node.yaml
(e.g. this), there is a missing example related toeventRecordQPS
, which makes it not consistent with other remediations.The text was updated successfully, but these errors were encountered: