Created attachment 1866441 [details] GCP SA console Description of problem: Customer wants to have some explanation about the following fact. The security team is highly concerned about this and is waiting for answers for a year now. "On GCP, the installer Service Account has a lot of permissions, as requested in the documentation. This Service Account create other service accounts for the registry, the machine operator, the masters, etc. Why all of these less privileged service accounts are created with "Service Account User role"? This permission allows for privilege escalation (allowing them to use the highly privileged installer account) and defeat the purpose of having dedicated service accounts for privilege separation." In this BZ I am focusing on the machine-api-operator. Here you can see the hard-coded role assigned to the service account: https://github.com/openshift/machine-api-operator/blob/release-4.6/install/0000_30_machine-api-operator_00_credentials-request.yaml#L111 Could you please explain why is Service Account User role necessary ? Is it expected ? I attach a screenshot of the service accounts in customer GCP console. Regards,
We have a near identical issue on AWS https://bugzilla.redhat.com/show_bug.cgi?id=2053871 The upshot of this is, that due to the design of the installation process of operators on OpenShift, and the cluster install itself and the limitations imposed by these. The service account user role is necessary so that we can create VMs. To boot an OpenShift node on a GCP VM, we must give the new VM a service account, for this, the user creating the VMs must have the service account user role. Now, on GCP, you can limit the service account user role to be able to pass only certain roles, which would be more secure. However, because the roles that the cloud credential operator applies come from the OpenShift release payload (that is the role is defined identically for every cluster on a particular version of OpenShift), we cannot limit them at all on a generic level. If a user is concerned about the privilege escalation here, they can create a new role for the Machine API operator that has a limitation on the service account user role, such that it can pass only the roles approved for usage by the VMs. For AWS, we are planning to write a KCS to resolve the issue and provide users instructions on how to create the more restrictive permissions, we should do the same here as well
@jspeed just curious if there is an update here?
No progress just yet, not sure who should really own this either. Credentials aren't limited to Machine API so perhaps there's better scope for this to be written in a more general sense
This is a low priority for us at the moment as users can workaround this by updating the credentials manually, we just need to write up the documentation for it.
This is still low priority, we will take a look when we can
I've spoken with the Hive team to get an understanding on how the CCO works when you want to use manual mode so should now have enough context to write up a KCS. I will try to get to this soon.
There's going to be some progress made on this with https://issues.redhat.com/browse/OCPCLOUD-1725 If the new permissions model allows us to restrict to resources, we can write a KCS similar to the one we have published for AWS, https://access.redhat.com/solutions/6981408
I've done some work on this today and if users so desire, they can switch their cluster into manual mode, remove the service account user role from the machine API service account, then grant it access to individual service accounts. I'm going to write up a KCS, but the commands they need to run will look something like gcloud projects remove-iam-policy-binding <project-name> --member="serviceAccount:<cluster-name>--openshift-m-<random-5-chars>@openshift-gce-devel.iam.gserviceaccount.com" --role="roles/iam.serviceAccountUser” gcloud iam service-accounts add-iam-policy-binding <cluster-name>-<random-5-chars>-w.gserviceaccount.com --member="serviceAccount:<cluster-name>--openshift-m-<random-5-chars>@openshift-gce-devel.iam.gserviceaccount.com" --role="roles/iam.serviceAccountUser" gcloud iam service-accounts add-iam-policy-binding <cluster-name>-<random-5-chars>-m.gserviceaccount.com --member="serviceAccount:<cluster-name>--openshift-m-<random-5-chars>@openshift-gce-devel.iam.gserviceaccount.com" --role="roles/iam.serviceAccountUser" The first of these removing the project level access, the second and third adding the access specifically for the worker and master roles created by the installer
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory (Moderate: OpenShift Container Platform 4.12.0 bug fix and security update), and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHSA-2022:7399