- Scan containers and Pods for vulnerabilities or misconfigurations.

- Run containers and Pods with the least privileges possible.

- Use network separation to control the amount of damage a compromise can cause.

- Use firewalls to limit unneeded network connectivity and encryption to protect confidentiality.

- Use strong authentication and authorization to limit user and administrator access as well as to limit the attack surface.

- Use log auditing so that administrators can monitor activity and be alerted to potential malicious activity.

- Periodically review all Kubernetes settings and use vulnerability scans to help ensure risks are appropriately accounted for and security patches are applied.

Some useful guidance here, although worth noting that some of it is a bit dated (k8s security can move quickly).

Most notably from a scan through, they're mentioning PodSecurityPolicy, but that's deprecated and scheduled to be removed in 1.25.

There will be an in-tree replacement but it won't work the same way. Out of tree open source options would be things like OPA, Kyverno, jsPolicy, k-rail or Kubewarden.

I used to study and focus on security a lot more and keep up with trends. After several interviews this year I realize a lot of jobs prioritize leetcode over everything else. It's pretty annoying and makes me wonder if the focus for tech works is leetcode above all else then no wonder so many companies have insecure apps and servers.

The elephant in the room here is almost all containers according to artifacthub.io, etc are a complete tire fire

A lot of this applies to containers in general. Not complaining, it's well written but wish they would break out the none kube container stuff into a general container-sec advice for people.

How do I know that this advice is useful and does not put me in danger?

Example: NSA recommends to use RSA encryption.

https://www.theverge.com/2013/12/20/5231006/nsa-paid-10-mill...

so... a lot of this can be done with Fairwind's OSS tool Polaris... https://github.com/FairwindsOps/polaris

feels good that we've been addressing this for a bit already tbh. (disclaimer, I work for fairwinds)

What yields the lowest risk - spending a ton of time hardening one cluster, or building multiple clusters to reduce the blast radius of bugs and misconfigurations?

A guide from somebody who hates not knowing everything about you... Tengo mis dudas

First you should configure some kind of authentication. It is fun to remember this 3 years old Tesla example [1]: Publicly accessible Kubernetes Dashboard.

[1] https://www.zdnet.com/article/tesla-systems-used-by-hackers-...

Well that’s… curious. Not sure I’ve ever read the NSA providing hardening guidance on anything before.

I keep forgetting NSA's job is to protect instead of maliciously eavesdropping on Americans. Given their prior probability of being a bad actor I'd take any security "guidance" they issue with a huge grain of salt.

This is really helpful. I wonder if there is curated list of k8s hardening guidelines for various organisations.

Do they have a version for ordinary web app servers?

We all know it's the National Insecurity Agency[0], and that the NSA hoards & stockpiles 0day. They very rarely release tools and research papers designed to strengthen our IT infra, since they sit on so much 0day. There's no balance.

I don't buy that they're 50% red team, and 50% blue team. More like 99% red team and 1% blue team.

[0] https://en.wikipedia.org/wiki/Doublespeak

Somehow the text is not just...

   kubectl -n my-ns delete pod,svc --all