amazon-eks-ami VS Wazuh

Careful assuming system reserved will be present. Last I checked, AWS EKS does not have system reserved resources for the kubelet by default and as a result, pods can starve those for resources (e.g., https://github.com/awslabs/amazon-eks-ami/issues/79). This is of course more important for memory, but could impact CPU as well.

For example, this is available for AL2: https://github.com/awslabs/amazon-eks-ami

I found this document that lists the pod limits per node size. I suspect you will want to consider larger worker nodes or you will very quickly be unable to schedule additional workloads.

source

Issue 1 is a known issue due to memory reservation being to low, see e.g. https://github.com/awslabs/amazon-eks-ami/issues/1145

No, the new node is added if there are not enough resiurces to start a new pod. So if you have many pods with small resource usage you can hit the pod per node limit, on eks you have a max number of pods depending on the instance type - https://github.com/awslabs/amazon-eks-ami/blob/master/files/eni-max-pods.txt You can incerase that limit : https://docs.aws.amazon.com/eks/latest/userguide/cni-increase-ip-addresses.html

# of pods are essentially capped by the worker node choice.

below excerpt from: https://github.com/awslabs/amazon-eks-ami/blob/master/files/...

  # Mapping is calculated from AWS EC2 API using the following formula:

See also: EKS nodes lose readiness when containers exhaust memory

So it manifests itself in this way: your pod is scheduled but remains pending forever. You check the logs and you see that it's complaining that the an IP address. Ultimately, if you check here, you see the maximum number of pods that can be scheduled on any underlying ec2 instance, even if you have remaining IPs in your subnet. I found this to be one of the most poorly understood phenomena in EKS. Even those who claimed to "crack" it and wrote fancy blog posts about it fundamentally got it wrong. AFAIK this document reflects the official AWS guide on how to mitigate this.

There is currently no feature for excluding specific SCA rules however this feature has been requested here and would be added to the roadmap for future releases.

I use Wazuh instead. Greenbone CE is severely limited and requires payment for anything beyond the very basic. Super simple installation more features.

Seems like something that should be documented somewhere more official than a random reddit post for sure. Added it to https://github.com/wazuh/wazuh/issues/1112 for good measure.

Hmm, I've really been wanting to try Wazuh but since all our endpoints (Win10/11) are running a German locale I've run into https://github.com/wazuh/wazuh/issues/16842 when checking the compliance checks (CIS benchmarks) on a test installation of 4.6.

Monitoring & Active Measures - Exporting firewall events to an external time-series database like I describe above is good to see who is touching your firewall or accessing your web site. Using an Intrusion Detection System / Intrusion Prevention System (IDS/IPS) such as open-source Suricata, which is a free package on pfSense, and deploying file system integrity monitoring, such as the open-source Wazuh on the exposed server are also good approaches to protecting yourself.

We are actively working on enhancing the system to allow users to mark vulnerabilities as "not vulnerable" or hide them. You can track the progress of this enhancement on the following GitHub issue: (Enhancement - Mark Vulnerabilities as Not Vulnerable).

Hello, thanks for using Wazuh, I will try to answer your questions: 1- I am going to check with the team in charge to see if there is a way. 2- Untriaged is a default value that is placed on vulnerabilities that do not have low, medium or high values https://github.com/wazuh/wazuh/issues/12675 3- As in the previous point, the providers of vulnerability lists have not provided the data.

Agents getting frequently pending and disconnecting