Document system:authenticated group usage in GKE

[alemorcuq]

We are binding the system:authenticated group to the service-proxier role so that kubeseal can easily communicate with the controller to get the public key and encrypt your secrets. This role only has permissions to get the sealed-secrets service and to make POST and GET requests to that service.

In GKE, the use of system:authenticated is discouraged because anyone with a Google account is assigned to that group. Here's a recent KubeCon talk on this topic that mentions our use case.

While nothing sensitive is exposed to users on that group, we should document this in our GKE documention. We should also add an option in the chart to allow users to disable the creation of the service-proxier service.

[keithjpaulson]

use of system:authenticated is more than discouraged; from google docs
"To help secure your clusters against mass malware attacks that exploit cluster-admin access misconfigurations, GKE clusters running version 1.28 and later won't allow you to bind the cluster-admin ClusterRole to the system:anonymous user or to the system:unauthenticated or system:authenticated groups."
I'd guess this will cause issues on GKE if the service-proxier isn't disabled, or group isn't changed?

[alemorcuq]

@keithjpaulson:

From your quote, it says that you won't be able to bind the cluster-admin ClusterRole to system:authenticated. Doing this effectively gives full admin rights to your cluster to anyone with a Google account, that's why Google is disabling it.

We are not doing that. We are binding a custom Role that only have permissions to do GET and POST requests to a specific service created by us.

[keithjpaulson]

@alemorcuq Correct, I read that part wrong -- they will just flag any use of system:authenticated as potentially insecure in console popups and emails that make administrators like me (who haven't touched sealed secrets) panic a bit. Apologies.