Update Standard "Baseline K8s Cluster Security" - rename to "K8s cluster hardening"

[cah-hbaum]

The "Baseline K8s cluster security" was created previously. In the PR (#376) there were some discussions about the structure and overall usefulness of the standard.
This issue should adapt the standard (since it is still in the draft phase) in order to better adhere to the requirements brought forward.
Some things to consider (citations) can be found in the comments of this issue.

Definition of Done:

• PR is reviewed and accepted by all people previously not content with the standard
• Follow-up issue for tests created --> [Testing] Tests for K8s cluster hardening issues#670

[cah-hbaum]

Comment from @artificial-intelligence at #376 (comment)

I find this very unspecific for a standards document.

Especially with regards to security this allows for many possible implementations which usually leads to - inadvertently - insecure implementations because there is no clear mandatory way to configure things in a secure fashion.

this is what opened many security holes in previous TLS standards, for example.

See this RFC for recommendations on how to write security related standards documents:

https://www.rfc-editor.org/rfc/rfc3552.html#page-26

I want to particularly highlight something relevant to the above:

If the technology involves authentication, particularly user-host
authentication, the security of the authentication method MUST be
clearly specified. That is, authors MUST document the assumptions
that the security of this authentication method is predicated upon.

So, to sum it up:

If you don't enforce secure authentication and authorization by the standard it's a matter of time until someone implementing your standard will end up implementing it in an insecure manner.

It is also not sufficient that the standard relies on third party security-by-accident schemes, made up example:

"the supported authentication schemes in kubernetes are all secure, therefore we do not need to specify explicitly secure auth schemes".

A standard should not rely on implementation specific behaviour, which might change in the future, or might be version specific.

Be explicit what is secure and be strict, not liberal in what you accept, see this famous criticism of the robustness principle:

https://datatracker.ietf.org/doc/html/draft-iab-protocol-maintenance

[cah-hbaum]

Started working on this issue and collected some sources again. I will update this comment with everything I found and read:

• https://cheatsheetseries.owasp.org/cheatsheets/Kubernetes_Security_Cheat_Sheet.html
• https://kubernetes.io/docs/concepts/security/
• https://kubernetes.io/docs/tasks/administer-cluster/securing-a-cluster/
• https://kubernetes.io/docs/concepts/security/controlling-access/