APP.4.4.A3

[sluetze]

Kubernetes und alle anderen Anwendungen der Control Plane MÜSSEN jede Aktion eines Benutzers oder, im automatisierten Betrieb, einer entsprechenden Software authentifizieren und autorisieren, unabhängig davon, ob die Aktionen über einen Client, eine Weboberfläche oder über eine entsprechende Schnittstelle (API) erfolgt. Administrative Handlungen DÜRFEN NICHT anonym erfolgen.

OpenShift beschränkt bereits in der Grundkonfiguration die Nutzung der Web-Console und der APIs nur auf authentifizierte und autorisierte Nutzer. Die Anbindung an externe Verzeichnisdienste (LDAP, OIDC und weitere) ist möglich.

rules:
 - api_server_anonymous_auth
 - kubelet_anonymous_auth

Jeder Benutzer DARF NUR die unbedingt notwendigen Rechte erhalten. Berechtigungen ohne Einschränkungen MÜSSEN sehr restriktiv vergeben werden. Nur ein kleiner Kreis von Personen SOLLTE berechtigt sein, Prozesse der Automatisierung zu definieren.

OpenShift bietet bereits Rollen für ein Least-Privilege-Konzept. Die RBAC-Rollen lassen sich anpassen oder durch neue Rollen ergänzen. Die vorkonfigurierten Rollen ermöglichen eine einfache Berechtigungsvergabe nach den Least-Privilege und Need-to-know Prinzipien. Über das Audit-Log können die Nutzer-Aktionen nachvollzogen werden.

rules:
 - kubeadmin_removed
 - rbac_least_privilege

Nur ausgewählte Administratoren SOLLTEN in Kubernetes das Recht erhalten, Freigaben für Festspeicher (Persistent Volumes) anzulegen oder zu ändern.

Persistent Storage kann in der Grundkonfiguration nur von Cluster-Administratoren integriert werden. Bei dynamisch provisioniertem Storage verfügen entsprechende Provisioner die notwendigen Berechtigungen. Diese Provisioner müssen von einem Admin eingerichtet und konfiguriert werden. Mittels der Quota-Mechanismen werden Storage-Anforderungen gesteuert und eingeschränkt.

- Manual check

[benruland]

This (manual) rule could also add value:

• rbac_limit_cluster_admin

[nrrso]

I think these rules might be relevant as well:

rules:
  - idp_is_configured
  - ocp_idp_no_htpasswd (not sure about this)
  - ocp_no_ldap_insecure

There are other rules under openshift/authentication/* which cover timeout, maxage and inactivity of oauth-tokens and make sense, but the control does not explicitly mention them, so I haven't included them.

[sluetze]

I think these rules might be relevant as well:

rules:
  - idp_is_configured
  - ocp_idp_no_htpasswd (not sure about this)
  - ocp_no_ldap_insecure

There are other rules under openshift/authentication/* which cover timeout, maxage and inactivity of oauth-tokens and make sense, but the control does not explicitly mention them, so I haven't included them.

I am fine with idp_is_configured since this might also stop people from removing kubeadmin without adding an IDP. Without IDP (no matter if htpasswd or not) and without kubeadmin, they lose access. I think with no_htpasswd we are overstretching the requirement.

ocp_no_ldap_insecure is imho out of scope. this is more APP.2.3.A6 which is not in focus. Maybe because of the structure of BSI Grundschutz we might have to also take a look into other buildingblocks and add such rules. Ill also take this over into customer meeting to get their input

I agree to not include the timeout controls, since they are not mentioned.

[sluetze]

https://github.com/ComplianceAsCode/content/pull/11501 was merged