regolibrary VS ingress-nginx

The question you're asking is missing the important piece: how useful are they _to whom_.

To a developer, think of them as glorified linters (most of them are, including Kubescape, I believe). Someone on your team chooses which included things should be flagged (e.g. "require resource limits to be set on pods", see the list here: https://github.com/kubescape/regolibrary), and then the tool yells at you when you try to do something it doesn't like. It's then up to you to figure out how to comply with the tool's decisions. Some people really like them, some people really hate them.

To an engineering manager or SRE team, I think they're great at preventing common errors that would otherwise be enforced through code reviews or other processes; they're basically the remediation after an outage where a pod OOMed ("if we set sane resource limits and enforce them, this won't happen" --> enforce resource limits policy).

To your company's legal and compliance team, they usually fulfill a checkbox requirement along the way to $COMPLIANCE_FRAMEWORK. By the time your company is at sufficient scale, you'll have a number of these, and automation is the only way to keep everyone sane (developers and auditors alike).

In general, I think they're well intentioned, and can be useful, but aren't a panacea--they aren't going to catch anything you're not already looking for, they're just going to make it easier to remedy/enforce the problems you already know about.

Kubescape retrieves the Kubernetes objects from the API server and scan them by running a set of snippets developed by ARMO.

I guess I was not understood correctly and I apologize for that. When a new CVE is reported, we publish a control testing and alerting users if they are exposed. For example when CVE-2021-25742 was reported, we published the control less than a day later.

ingress-nginx

The second one is a combination of tools: External DNS, cert-manager, and NGINX ingress. Using these as a stack, you can quickly deploy an application, making it available through a DNS with a TLS without much effort via simple annotations. When I first discovered External DNS, I was amazed at its quality.

resource "helm_release" "icrelease" { name = "nginx-ingress" repository = "https://kubernetes.github.io/ingress-nginx" chart = "ingress-nginx" version = "4.9.1" namespace = kubernetes_namespace.icnamespace.metadata[0].name set { name = "controller.ingressClassResource.default" value = "true" } }

helm repo add ingress-nginx https://kubernetes.github.io/ingress-nginx helm repo update helm upgrade --install ingress-nginx ingress-nginx/ingress-nginx --namespace ingress-nginx --create-namespace -f custom/ghost/nginx.yaml

For example, if you chose Nginx Ingress, you will use some of its dozens of annotations that are not portable if you decide to switch to another Ingress implementation like Apache APISIX.

The controller is installed with helm upgrade --install ingress-nginx ingress-nginx --repo https://kubernetes.github.io/ingress-nginx --namespace ingress-nginx --create-namespace

helm repo add jetstack https://charts.jetstack.io helm repo add ingress-nginx https://kubernetes.github.io/ingress-nginx helm repo add rancher-latest https://releases.rancher.com/server-charts/latest helm repo update helm repo list

Everything in the YAML snippets below — except for ingress configuration — relates to configuring the NGINX ingress controller. This includes customizing the default configuration.

Keep Documentation Handy: Always have the official NGINX Ingress documentation accessible.