- Más nuevo
- Más votos
- Más comentarios
Hello,
Firstly, note that whenever we assign an SSO user with a permission set to an AWS account present in your Organization, AWS SSO creates an IAM role in that assigned account with the policies attached to the permission set. Depending upon the permission policies attached to that permission set, your SSO user will access the resources present in your account using that IAM role.
Secondly, I am referencing the limits of permissions policies that can be attached to SSO permission set:
- By default, number of AWS managed policies that can be attached to a permission set is 10. However, this can be raised upto 20 as we describe in our AWS docs here - "AWS Identity and Access Management (IAM) sets a quota of 10 managed policies per role. To take advantage of this quota, request an increase to the IAM quota Managed policies attached to an IAM role in the Service Quotas console for each AWS account where you want to deploy the permission set."
- Note - The maximum limit for attaching a managed policy to an IAM role or user is 20.
https://aws.amazon.com/premiumsupport/knowledge-center/iam-increase-policy-size/
- The number of custom permission policy (inline policy) that can be attached to a permission set is 1 and this is a hard limit. Also, the maximum size of inline policy per permission set is 10,240 bytes and the same cannot be increased further.
Thirdly, as for comparing IAM inline policy vs Identity Center's quota, note that with IAM service, you can add as many inline policies as you want to an IAM user, role, or group. But the total aggregate policy size (the sum size of all inline policies) per entity cannot exceed the following limits:
- User policy size cannot exceed 2,048 characters.
- Role policy size cannot exceed 10,240 characters.
- Group policy size cannot exceed 5,120 characters.
While in reference to Identity Center the character limit for inline policy per permission set is 10,240 bytes.
Also, I would like to mention that there is already a feature request in place with the Identity Center Development team to support multiple inline policies in SSO permission sets. Kindly note that AWS take customer’s feedback very seriously, as this allows AWS to better prioritize new features/improvements down the road. Please be assured that I will perform my due diligence in ensuring that your case is used as supporting evidence.
Unfortunately, it would not be possible for me to furnish you with an ETA on this feature since support engineers are not made privy to development road-maps and do not have visibility into the development timelines. Therefore, I would request you to monitor our products announcement page and AWS News Blog periodically for updates regarding announcements for AWS services
[+] What's New at AWS: https://aws.amazon.com/new/
[+] AWS Blog: https://aws.amazon.com/blogs/aws/
Having said that, as it is not possible to attach multiple inline policies in AWS SSO permission set, I would kindly request you to add all the IAM policies in a single inline policy and attach it to the SSO permission set. However, if your inline policy has reached the limit of 10,240 bytes then I'm afraid to inform you that the only possible workaround is to cut-down the characters in the inline policy to be within the limit of 10,240 bytes. You can also parse through your custom policy (either inline or customer managed) and consolidate several actions by using a “” ( for example: ec2:Describe, ec2:List*, ec2:Get*).
Finally, coming to your query of usage and best practices, with Identity Center, you get the benefits of the following -
- Identity Center provides users in this identity source with a personalized user portal from which they can easily launch multiple AWS accounts or cloud applications.
- Inside the IAM Identity Center console, you can leverage application assignments to provide single sign-on access to many SAML 2.0 business applications, including Salesforce, Box, and Microsoft 365.
- Users sign in to the portal using their corporate credentials or with credentials they set up in AWS SSO. Once they sign in, they have one-click access to all applications and AWS accounts that you have previously authorized.
You can read more about fine grained permissions and assignments here -
https://docs.aws.amazon.com/singlesignon/latest/userguide/abac.html
Contenido relevante
OFICIAL DE AWSActualizada hace un año- OFICIAL DE AWSActualizada hace 3 años
I agree with everything that Yash_C says in their highly comprehensive write up. I would also like to add that there are other layers of permissions that can be leveraged to reduce IAM and IAM Identity Center policies such as Service Control Policies (SCP) and resource-based policies, see https://aws.amazon.com/blogs/security/iam-policy-types-how-and-when-to-use-them/. SCPs are useful for organization-wide controls like regions and AWS services that are denied, see https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps_examples.html. Here are example of resource-based policies for Amazon S3 -> https://docs.aws.amazon.com/AmazonS3/latest/userguide/example-bucket-policies.html.