Document system:authenticated group usage in GKE
alemorcuq opened this issue · comments
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.
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?
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.
@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.