Closed frankpengau closed 6 months ago
One thing that I would like to add, is that this is run via a pipeline and timed out after 8 hours.
For example, having limited it to 1 Managed Policy Attachment can take over an hour and still be stuck on "Still Creating..." and I have triple checked and it is not a duplicate managed policy attachment issue, like the one referenced in issue: #21543
Also the ThrottlingException can also be seen in CloudTrail, as follows:
"eventTime": "2022-06-23T16:02:20Z",
"eventSource": "sso.amazonaws.com",
"eventName": "DescribePermissionSet",
"awsRegion": "ap-southeast-2",
"sourceIPAddress": "12.34.56.78",
"userAgent": "APN/1.0 HashiCorp/1.0 Terraform/1.0.7 (+https://www.terraform.io) terraform-provider-aws/dev (+https://registry.terraform.io/providers/hashicorp/aws) aws-sdk-go/1.44.34 (go1.17.6; linux; amd64)",
"errorCode": "ThrottlingException",
"errorMessage": "Rate exceeded",
"requestParameters": null,
"responseElements": null,
"requestID": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
"eventID": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
"readOnly": true,
"eventType": "AwsApiCall",
"managementEvent": true,
"recipientAccountId": "123456789012",
"eventCategory": "Management",
"tlsDetails": {
"tlsVersion": "TLSv1.2",
"cipherSuite": "XXXXX-XXX-XXXXXX-XXX-XXXXXX",
"clientProvidedHostHeader": "sso.ap-southeast-2.amazonaws.com"
}
Hello,
I am encountering a similar issue with Identity Center.
Using the following block :
data "aws_identitystore_user" "this" {
identity_store_id = var.identity_store_id
filter {
attribute_path = "UserName"
attribute_value = var.username
}
}
We get the following type of error in the terraform log :
│ Error: reading AWS SSO Identity Store User Data Source (d-xxxxxxxxxx): operation error identitystore: DescribeUser, https response error StatusCode: 400, RequestID: xxxxxxxxx, deserialization failed, failed to decode response body, invalid character '<' looking for beginning of value
│
│ with data.aws_identitystore_user.this,
│ on data.tf line xx, in data "aws_identitystore_user" "this":
│ 17: data "aws_identitystore_user" "this" {
After investigating in the AWS Cloudtrail, I noticed that it is indeed rate limiting :
{
"eventVersion": "1.08",
"eventTime": "2022-10-25T14:47:41Z",
"eventSource": "sso.amazonaws.com",
"eventName": "ListAccountAssignments",
"awsRegion": "eu-west-1",
"sourceIPAddress": "xx.xx.xx.xx",
"userAgent": "APN/1.0 HashiCorp/1.0 Terraform/1.2.9 (+https://www.terraform.io) terraform-provider-aws/dev (+https://registry.terraform.io/providers/hashicorp/aws) aws-sdk-go/1.44.117 (go1.18.4; linux; amd64)",
"errorCode": "ThrottlingException",
"errorMessage": "Rate exceeded",
"requestParameters": null,
"responseElements": null,
"requestID": "xxxxxx",
"eventID": "xxxxxx",
"readOnly": true,
"eventType": "AwsApiCall",
"managementEvent": true,
"recipientAccountId": "xxxxxxx",
"eventCategory": "Management",
"tlsDetails": {
"tlsVersion": "TLSv1.2",
"cipherSuite": "ECDHE-RSA-AES128-GCM-SHA256",
"clientProvidedHostHeader": "sso.eu-west-1.amazonaws.com"
}
}
Did you find a workaround while waiting for your MR to be accepted ?
I am running into this issue pretty heavily. Has anyone figured out a solution? We have about 30ish permission sets with about 50 groups getting assigned them and we can't even plan without the rate limit.
│ Error: reading SSO Managed Policy Attachment (arn:aws:iam::aws:policy/ReadOnlyAccess,arn:aws:sso:::permissionSet/ssoins-STUFF/ps-STUFF,arn:aws:sso:::instance/ssoins-STUFF): operation error SSO Admin: ListManagedPoliciesInPermissionSet, failed to get rate limit token, retry quota exceeded, 2 available, 5 requested
I too have run into this issue. In my case, the cause seems to be an over-configuration of parallelism.
$ echo $TF_CLI_ARGS_plan
--parallelism=100000
$ echo $TF_CLI_ARGS_apply
--parallelism=100000
I rolled back it to the default of 10. The problem no longer occurs.
This functionality has been released in v5.42.0 of the Terraform AWS Provider. Please see the Terraform documentation on provider versioning or reach out if you need any assistance upgrading.
For further feature requests or bug reports with this functionality, please create a new GitHub issue following the template. Thank you!
I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues. If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.
Hey Terraform AWS Provider Community,
Hope you're all well.
I'm having an issue with the AWS SSO Admin service in terraform aws provider.
To give a brief background, we are using SSOAdmin to spin up about 40+ Permission Sets, to correlate with our 40+ IAM Roles.
Each permission set will have an inline policy and a managed policy set. Afterwards, it will have an account assignment for a specific environment (aws account), targeting a specific aws sso group.
We've structured the setup as modules:
An example of one of our Permission Set terraform files:
An example of one of our Policy terraform files:
An example of one of our Account Assignment terraform files:
We have issues with the terraform stuck with "Still Creating..." for a large number of AWS SSO Calls.
We have tried to set the TF_CLI_ARGS_apply = "-parallelism=1" and also diagnose the issue via TF_LOG_PROVIDER=DEBUG.
What we are currently running into, is issues with the terraform aws provider making too many calls to the AWS SSO APIs (aws-sdk-go) causing a Throttling Exception: Rate exceeded error, when making DescribePermissionSet calls too often, in order to validate that the permission set has been set, due to the eventual consistency nature of those CreatePermissionSet calls.
According to the AWS SSO Quota for AWS SSO throttle limits:
Source: https://docs.aws.amazon.com/singlesignon/latest/userguide/limits.html#ssothrottlelimits
So we suspect that we are hitting the 20 TPS limit and therefore encountering the Throttling Exception. Is there a way to reduce the number of calls for validating the permission sets per second? So that we don't go over the limit?
A sample of the DEBUG logs: