[Standardization] Baseline K8s cluster security (#415)

[cah-hbaum]

This PR adds a standard for high security setups, which should increase the overall of a Kubernetes cluster.
Edit: After communicating with @joshmue, this is being renamed into "Baseline K8s cluster security", since we only put up a few points which should be important for a starting security setup.

Closes SovereignCloudStack/issues#415

[cah-hbaum]

This standard is written for now but probably needs a rework.
I needed to read a bit about Kubernetes security and hardening. IMO, it all makes sense, but the standard itself isn't really nice to read through, since it only says what to do very general. If someone needs more details for this, they need to read the Design considerations section or go more in-depth in the K8s documents.

Please make some improvements to the text or some proposals about additional hardening steps if they seem useful to you.

What I also found problematic is that this standard is one of those that can't be made MANDATORY (so I couldn't write MUST for the entire standard), since not all clusters need to be "secure" or it's just not possible for specific setups.
I think this makes more sense for clusters that are sold as "High Security", which should adhere to this standard.

[garloff]

Nice work, Hannes!
What we need to do is to start having a discussion with our container team:

• Do we find consensus on what we recommend and what we require?
• Can we implement all of this in Cluster Stacks? And could we at least implement this in good old k8s-cluster-api-provider? (We need to decide how much of this we still want to add to old v1 KaaS which has only a limited life time left --things that are risky, very tedious for us or have the effect of breaking users or requiring significant changes on their side are probably not good for our old solution.)

@jschoone - can you take it there?

[cah-hbaum]

Updated the document to be about baseline security measures just how it was exchanged with @joshmue.
CIS benchmark documents aren't included in this for now, since I couldn't read them yet but I will try to get on top of that this week.

[jschoone]

Hi @bitkeks, @cah-hbaum and @joshmue. What's the state here? It looks like we have enough approvals to merge before it gets more complicated.

[bitkeks]

LGTM, already approved!

@artificial-intelligence has remaining changes that need to be resolved.

[cah-hbaum]

TBF I don't know how to adapt the document to "appeal" more to the requested changes from @artificial-intelligence. Either he suggests some general changes (like he's written in his comment) or approves or we will be stuck here.

[jschoone]

Hi @artificial-intelligence, could you please add suggestions to your change requests? Otherwise we would like to merge, since this is in Draft state we can add improvements later.

[cah-hbaum]

Pinging @artificial-intelligence again, since the last time was two weeks ago. I still don't know how to change the paragraphs up in order to make it compliant with your vision of them.

[artificial-intelligence]

Hi @artificial-intelligence, could you please add suggestions to your change requests? Otherwise we would like to merge, since this is in Draft state we can add improvements later.

I don't find it reasonable to expect from reviewers to redraft completely missing necessary implementation details for a standards document.

This is work that is expected to be done by the authors of the document imho, because that is the main thing which needs to be done, when drafting such a document.

I'll thus remove myself from the reviewers of the document. I don't have currently the time to write the necessary detailed spec to make authn and authz reasonable secure. As this is completely left for the implementer to decide - and people will get this wrong, sooner or later - I guess there is no consensus here on how to do secure RBAC authn/autz, so even if I had the time, I can't write something down when there is no consensus, which is the point of standards.

I wish you good luck with the ongoing effort to secure Kubernetes.

[artificial-intelligence]

I don't seem to be able to remove myself from this review somehow. Two days ago I didn't show up when I removed myself. Now I'm again listed as a reviewer.

[cah-hbaum]

Worked now it seems like.

[artificial-intelligence]

It seems I at least need to leave a comment to get out of here, so here you are 🙂

[artificial-intelligence]

It seems github review is totally broken. I need to either request changes (I didn't want to request further changes) or I need to approve the change (I honestly don't want to approve it).
I can't remove myself from the review, at this stage, through the Github UI.

But as we are stuck with this, I just "approved" this now.

[cah-hbaum]

Merging this now, we will continue in #475 to address issues brought up here.