Support for Managing AWS SSO Permission Sets

[sean-nixon]

Community Note

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
• Please do not leave "+1" or other comments that do not add relevant new information or questions, they generate extra noise for issue followers and do not help prioritize the request
• If you are interested in working on this issue or have submitted a pull request, please leave a comment

Description

AWS just announced "account assignment" APIs for AWS SSO. This allows programmatic management of permission sets and assignments to accounts with those permission sets. Looking into the APIs, it looks like user/group IDs will require additional data sources using the "IdentityStore" APIs, which I'll leave for a separate feature request. It would be wonderful if we could manage permission sets and their associated policies with Terraform. Right now, it is incredibly painful to manage these manually through the console, especially if you want to use custom inline policies.

New or Affected Resource(s)

• aws_sso_permission_set
• aws_sso_permission_set_policy
• aws_sso_permission_set_policy_attachment
• aws_sso_account_assignment

Potential Terraform Configuration

resource "aws_sso_permission_set" "example" {
  name        = "MyCustomPermissionSet"
  description = "Created by Terraform"
  # Can probably retrieve the SSO instance as a data source? It doesn't show up anywhere in the AWS Console,
  # but I was able to find it by using the browser dev tools to view the requests being made and it's using this API.
  # https://docs.aws.amazon.com/singlesignon/latest/APIReference/API_ListInstances.html
  instance_arn = "arn:aws:sso:::instance/ssoins-abc123xyz987"
}

resource "aws_sso_permission_set_policy" "example_inline_policy" {
  permission_set_arn = aws_sso_permission_set.example.id

  policy = <<-EOF
  {
    "Version": "2012-10-17",
    "Statement": [
      {
        "Action": [
          "ec2:Describe*"
        ],
        "Effect": "Allow",
        "Resource": "*"
      }
    ]
  }
  EOF
}

resource "aws_sso_permission_set_policy_attachment" "example_managed_policy" {
  permission_set_arn = aws_sso_permission_set.example.id
  managed_policy_arn = "arn:aws:iam::aws:policy/AWSServiceCatalogAdminFullAccess"
}

# Retrieved using the IdentityStore API. SSO User/Group Data Sources are Out of scope for this issue
# https://docs.aws.amazon.com/singlesignon/latest/IdentityStoreAPIReference/welcome.html
data "aws_sso_user" "my_user" {
  identity_store_id = "d-12345678"
  display_name      = "[email protected]"
}

resource "aws_sso_account_assignment" "example" {
  permission_set_arn = aws_sso_permission_set.example.id
  principal_type     = "USER"
  target_id          = data.aws_sso_user.my_user.id
}

References

• Announcement: https://aws.amazon.com/about-aws/whats-new/2020/09/aws-single-sign-on-adds-account-assignment-apis-and-aws-cloudformation-support-to-automate-multi-account-access-management/
• API reference: https://docs.aws.amazon.com/singlesignon/latest/APIReference/welcome.html

[tedivm]

Being able to manage permission sets with terraform would make life so much easier.

[moserke]

User/Group IDs can be discovered through the Identity Store APIs. https://docs.aws.amazon.com/singlesignon/latest/IdentityStoreAPIReference/welcome.html Using a filter of DisplayName you can discover the id which would then be usable in calls to the SSO apis.

[bflad]

My suggestion would be to create a separate feature request outlining any potential Identity Store data sources.

[sean-nixon]

@bflad Good point. I had updated my original description to add the data sources, but it probably makes sense as a separate issue. I'll revert.

[mao65fi]

What about other settings, like using external identity source e.g. Azure AD. There one would need to define also Authentication and SCIM settings and output the related values. In that case principals would be groups originated from AAD, and one could use a data resource to get the group Id based on the group name.

[reegnz]

@mao65fi I feel that identity provider integration is out of scope for this ticket, and AWS also has not yet provided an API for changing those settings either, so you should knock on their door first.

This issue should focus on what we already have and that's the permission set handing.

[burck1]

Hi! I desperately need these Terraform resources in my life ;). I'm interested in working on this issue and submitting a PR. Is anyone else already working on this? I see that @bflad has already merged in the corresponding SDK changes so I'm hoping it's relatively straight-forward.

Note: I've been a pretty heavy user of AWS SSO since it was released last December, so I'm happy to help design & test if someone else is already working on it.

[sklarsa]

Following up on @burck1's comment, I'm also happy to assist ongoing efforts with this issue. Is anyone currently working on this?

[burck1]

Hi @sklarsa! I've started this work a bit. Right now I really just have the scaffolding for an aws_sso_permission_set resource. I can open a WIP PR today to show what I have.

For splitting up the work, I was thinking of doing separate PRs; one for the aws_sso_permission_set resource and one for the aws_sso_assignment resource. I'm basing this split on the corresponding CloudFormation design. https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/AWS_SSO.html. I also suspect we'll need some corresponding data sources.

What I haven't yet figured out is how & when to provision the permission set. https://docs.aws.amazon.com/singlesignon/latest/APIReference/API_ProvisionPermissionSet.html I.E. Whenever any of the properties of the aws_sso_permission_set resource are updated, the ProvisionPermissionSet API will need to be called to push those changes to the associated accounts.

[burck1]

To help us to continue to move forward, please go give a thumbs up on #15808.

We've completed most of the work for supporting the AWS SSO and AWS SSO Identity Store resources and datasources in Terraform. The #15322 [WIP] PR encompasses all of that work. But, the contribution guide for this repo recommends submitting small pull requests with the minimum required resources, so we've submitted #15808 as our initial PR with just data.aws_sso_instance, data.aws_sso_permission_set, and aws_sso_permission_set. Once that's merged, we will submit PRs for all of the other resources and data sources since they depend on that initial PR.

[breathingdust]

Hi all 👋, just wanted to point to our recently published public roadmap which features a commitment to support this feature. We are little behind on our previous quarter commitments, but as soon as we have an engineer available we will be in touch to start the review process.

Thanks to @burck1 and others for the all the work so far, this is a very popular feature and we're looking forward to making in available in the provider soon!

[burck1]

Hi @breathingdust. That's great!

One change I would recommend updating in the roadmap would be the resources listed. Based on #15322, we should list:

New Resources

• aws_sso_permission_set
• aws_sso_assignment

New Data Sources

• aws_sso_instance
• aws_sso_permission_set
• aws_identity_store_group
• aws_identity_store_user

Thanks!

[TomNorth]

A suggestion to make the aws_sso_assignment resource easier to work with, could this consider an accounts data source? This would support globbing, since a lot of organisations use naming conventions for AWS accounts based on teams/services using them. So as a simple example:

data awssso_accounts "team-name" {
  search_patterns = ["aws-serviceA-*", "aws-teamA-*", "aws-storage-*"]
}

That way, using a foreach we could create multiple assignments shortly and concisely. If the above returns a map of AccountName => AccountId, then we use foreach in the aws_sso_assignment resource to ensure we create assignments for that group for each of the accounts we intend them to have access to, within one simple block, rather than having to explicitly create a block for every single account that the group with have this permission set in.

Indeed, to create an Admin permission set provisioned across all accounts in an organization, that you might wish to provide your administrative team, the search_patterns would just be ["*"] to create the association everywhere.

[burck1]

Hi @TomNorth. Great idea! Though I don't think the AWS SSO API provides a mechanism to get a list of accounts, you should be able to use the aws_organizations_organization data source for a similar purpose.

data "aws_organizations_organization" "example" {}

output "account_names" {
  value = data.aws_organizations_organization.example.accounts[*].name
}

output "account_ids" {
  value = data.aws_organizations_organization.example.accounts[*].id
}

Then once you have the accounts list, you should be able to filter the results using some of terraform's interpolation functions.

[anGie44]

Initial support for managing SSO permission sets, inline and managed policy attachments has been merged and will release with v3.23.0 of the Terraform AWS Provider.

[anGie44]

Hi @sean-nixon et al. 👋 Noting here that additional support for managing SSO Account Assignments and reading individual IdentityStore User and Group has been merged and will release with v3.24.0 of the Terraform AWS Provider, likely out later today.

Added support includes:

• data_source_aws_identitystore_user
• data_source_aws_identitystore_group
• resource_aws_ssoadmin_account_assignment

[ghost]

This has been released in version 3.24.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 for triage. Thanks!

[ghost]

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 feel this issue should be reopened, we encourage creating a new issue linking back to this one for added context. Thanks!