-
Notifications
You must be signed in to change notification settings - Fork 33
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
IAM trust error with cross-account shared VPC #82
Comments
The installer role permission policy should include the permission for "sts:AssumeRole" and "sts:AssumeRoleWithWebIdentity", it does not specify which roles to assume though. Could you help to ensure those are within the set of permissions for |
Hi Guilherme, thanks for getting back to me. I went through my findings again and double checked the parts you mentioned.
# ROSA-SharedVPCRole-rosa-pbit-my-cluster-Z01724557PTJ8IV92KS3
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::222222222222:root"
},
"Action": "sts:AssumeRole"
}
]
}
# rosa-pbit-my-cluster-account-Installer-Role (from account 222222222222)
{
"Statement": [
{
"Action": [
...
"sts:AssumeRole",
"sts:AssumeRoleWithWebIdentity",
"sts:GetCallerIdentity",
...
],
"Effect": "Allow",
"Resource": "*"
},
{
"Action": [
"secretsmanager:GetSecretValue"
],
"Condition": {
"StringEquals": {
"aws:ResourceTag/red-hat-managed": "true"
}
},
"Effect": "Allow",
"Resource": "*"
}
],
"Version": "2012-10-17"
}
In this instance, it is the "rosa-pbit-my-cluster-operator-openshift-ingress-operator-cloud-creden" role that is trying to assume the SharedVPCRole. That role does not have appropriate rights to assume roles in another account: {
"Statement": [
{
"Action": [
"elasticloadbalancing:DescribeLoadBalancers",
"route53:ListHostedZones",
"route53:ListTagsForResources",
"route53:ChangeResourceRecordSets",
"tag:GetResources"
],
"Effect": "Allow",
"Resource": "*"
}
],
"Version": "2012-10-17"
} Thoughts? |
For the Regarding the permission policy of the ingress operator it should have picked up this set of permissions when the shared vpc role is supplied, I'll take a look into it Edit: I have identified that the main module seems to be missing the shared vpc role arn input forwarding so that the operator policies may route to the correct permission set mentioned above. I'll be bringing that to the team and provide an estimate for a fix soon. In the meantime as a workaround please check the shared vpc example, you'll notice that it relies on the standalone modules instead of the main module directly |
The trust policy we have there (arn:aws:iam:111111111111:root) should actually be more permissive than what's described in the doc you linked. It allows ANY principal from the specified account to assume the role. I'm glad you were able to confirm the other issue. Please do keep me posted on when you think the fix might be available. For now, I will need to proceed with the legacy rosa-sts module since I have that working and am under the gun a touch. But I would love to be able to shift gears to the new providers asap if that becomes feasible. |
On further inspection that is correct and it seems to be working internally on my tests using the more permissive :root as well, albeit be in mind some aws services do not work well through that setup and require the use of more specific restriction. My current explanation is that it was a sync delay on AWS side for it to pick up and accept the installer role. For the second issue it is indeed because the main module is not forwarding the intent of use of the We are currently going through the release of v1.6.3 of the provider, so that fix will be included in v1.6.3 of the classic modules |
Any update on where we're at with this? I saw that v1.6.3 was released but it doesn't look like the fix made it in. |
We had an issue with 1.6.2 modules that required the 1.6.3 release early, the PR has been merged to main and will be available for 1.6.4. Sorry about that inconvenience |
Roger that. Do you have a ballpark ETA on that one?
|
I am trying to deploy a private ROSA STS cluster that leverages an existing shared VPC in another AWS account. We have previously had this configuration working successfully with the legacy rosa-sts module. Example resource configuration with the new rosa-classic module is below.
When attempting to deploy with this configuration, we receive the following error:
Our troubleshooting has suggested that the trust policy on the ROSA-SharedVPCRole-my-cluster role is configured properly. However, the identity policies on the my-cluster-Installer-Role do not include the requisite permissions that allow it to assume the ROSA-SharedVPCRole-my-cluster role.
The text was updated successfully, but these errors were encountered: