Description of problem: According to a cco user story https://issues.redhat.com/browse/CCO-104, in-cluster CredentialsRequest needs serviceAccountNames field like this https://github.com/openshift/cloud-credential-operator/blob/master/manifests/05-iam-ro-credentialsrequest.yaml#L23-L24 without the field, when the customers use ccoctl tool to create sts related resources will hit the below error: ##### 2021/12/07 11:02:07 Failed to process IAM Roles: Failed while processing each CredentialsRequest: error while creating Role policy document for openshift-cluster-api-aws: CredentialsRequest must provide ServieAccounts to bind the Role policy to ##### Version-Release number of selected component (if applicable): 4.10.0-0.nightly-2021-12-02-140313 How reproducible: always Steps to Reproduce: 1.extract ccoctl from ocp release image $export RELEASE_IMAGE= registry.ci.openshift.org/ocp/release:4.10.0-0.nightly-2021-12-06-201335 $CCO_IMAGE=$(oc adm release info --image-for='cloud-credential-operator' $RELEASE_IMAGE) $oc image extract $CCO_IMAGE --file="/usr/bin/ccoctl" -a ~/.pull-secret $chmod +x ccoctl 2.extract CredentialsRequest $oc adm release extract --credentials-requests --cloud=aws --to=./credrequests-gcp $RELEASE_IMAGE 3.run ccoctl $./ccoctl aws create-all --name=lwan-ccoctl --region=us-east-2 --credentials-requests-dir=./credrequests Actual results: it will hit an error ##### 2021/12/07 11:02:07 Failed to process IAM Roles: Failed while processing each CredentialsRequest: error while creating Role policy document for openshift-cluster-api-aws: CredentialsRequest must provide ServieAccounts to bind the Role policy to ##### Expected results: it shoudn't Additional info: the related PR is https://github.com/openshift/cluster-capi-operator/pull/15
This BZ should/could be about both AWS and GCP. We recently added GCP Workload Identity support which works nearly identically to the AWS implementation, and the GCP CredentialsRequest would also require the ServiceAccountNames field to be set appropriately.
just trying to figure out the proper component, @lwan is this a problem with the capi operator or with the ccoctl tool?
(In reply to Michael McCune from comment #2) > just trying to figure out the proper component, @lwan is this a > problem with the capi operator or with the ccoctl tool? No need to wait for Lin to respond while I'm online :). The ccoctl tool can no longer make IAM Roles while processing a CredentialsRequest if the SeriviceAccountNames field is empty. ccoctl locks down access to the IAM Role via the namespace/name of the ServiceAccount(s). Don't know why the TODO in the code is still lying around, but it sums things up nicely https://github.com/openshift/cloud-credential-operator/blob/master/pkg/cmd/provisioning/aws/create-iam-roles.go#L259-L263: // We used to support leaving the list of ServiceAccounts blank in the CredentialsRequest while // we transitioned all the existing CredReqs. That work is complete, and we should not // create Role policies that limit the Role by audience any more. // Return an error indicating that ccoctl requires the ServiceAccount list to be populated. In the absence of the ServiceAccountNames, ccoctl has nothing to restrict which ServiceAccounts inside the cluster are allowed to AssumeRole() to the target IAM Role. As a transition, we allowed AssumeRole() from any ServiceAccount with the "right" audience field, but (for example) that means any ServiceAccount in the cluster can AssumeRole to the IAM Role that is meant for the machine-api-operator (not a good security situation). But now that all in-cluster CredentialsRequests populate the ServiceAccountNames field, we took away that transitional support.
thanks for the explanation Joel. it sounds like we need to update the CredentialsRequests in this file[0] to add the ServiceAccountNames ? [0] https://github.com/openshift/cluster-capi-operator/blob/main/manifests/0000_30_capi-operator_00_credentials-request.yaml
Yes for both GCP and AWS. And in an ideal world we'd also update the permissions in that GCP CredentialsRequest to not use the beta level loadbalanceradmin role too.
perfect, thanks for the confirmation and extra context.
hey all, i didn't realize we had this open when we hit the error earlier today. subsequently we created a new bug, https://bugzilla.redhat.com/show_bug.cgi?id=2037061, and i have posted a pull request to fix the issue. i am marking this bug as a duplicate of the other, even though we opened this one first. apologies for the confusion. *** This bug has been marked as a duplicate of bug 2037061 ***