aws-samples / iam-identity-center-team

Open-source temporary elevated access solution for AWS IAM Identity Center.

Home Page:https://aws-samples.github.io/iam-identity-center-team/

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

[Feature Request]: How to use GraphQL API to manage Eligibility and Approval Policies

lvthillo opened this issue · comments

Use case:
We have more than 250+ AWS accounts. Every week we need to create a couple of new accounts and decom some old ones. Here for we have 2 step function flows which automate this. The flow will create the correct networking stuff for new accounts, update owner + alternate contacts, correct OU, SSO stuff, ... . Similar for cleanup when we decom an account.

Now with the current TEAM solution it seems we have to configure / update our eligibility and approval policies every time a new account is added or removed. AFAIK we can use the UI. But is there a way to do this by using an API? I saw it's using a GraphQL API. Based on owner, team, group, lead etc. we can decide in our Step Function flow which SSO group can request temporary access and who can approve it. So it would be very useful if we can talk to the TEAM API to manage those policies instead of having to manage them manually in the UI. Can we use the GraphQL API here for and how can we authenticate? Is there some documentation for it? Of course these questions are only valid if it's possible to do it with an API.

@lvthillo first of all thanks for you contribution so far to TEAM.

Enabling API access for admin actions such as creating approver and eligibility policy is one of the top priorities in our backlog. The graphql APIs exisit but we need to be able to expose this in a secure and scalable fashion.

Before Finding this, I made this discussion post: #131

I also am eager to have some method to programmatically interact with the API. I am wanting to write a terraform provider for TEAM as our team does all of our automation in Terraform.

I am willing to write the terraform provider and publish it once we have this feature.

During writing the API, I will likely be writing a separate go SDK for TEAM as well to allow other teams to utilize it within golang easier.

I already have a working data source to read the "settings" as I am able to hit the api for read operations. You can see the resource tests for settings are failing as the permissions are not there yet for create actions:

TF_ACC=1 go test ./... -v  -timeout 120m
?       github.com/brittandeyoung/terraform-provider-awsteam    [no test files]
?       github.com/brittandeyoung/terraform-provider-awsteam/internal/envvar    [no test files]
?       github.com/brittandeyoung/terraform-provider-awsteam/internal/sdk/awsteam       [no test files]
=== RUN   TestAccSettingsDataSource
--- PASS: TestAccSettingsDataSource (3.37s)
=== RUN   TestAccSettingsResource_basic
    settings_test.go:20: Step 1/3 error: Error running apply: exit status 1
        
        Error: Client Error
        
          with awsteam_settings.test,
          on terraform_plugin_test.tf line 12, in resource "awsteam_settings" "test":
          12: resource "awsteam_settings" "test" {
        
        Unable to create settings, got error: Message: Not Authorized to access
        createSettings on type Mutation, Locations: [{Line:2 Column:3}], Extensions:
        map[]
--- FAIL: TestAccSettingsResource_basic (1.39s)
FAIL
FAIL    github.com/brittandeyoung/terraform-provider-awsteam/internal/provider  5.407s
FAIL
make: *** [testacc] Error 1

Once this feature is live, I plan on publishing a working provider shortly after.

@brittandeyoung thanks for making a start at this. The settings and policy configuration can only be mutated by a persona who is a member of the TEAM admin group. We would have to work out a way to grant programmatic access (outside of the group based authorisation) to those API to make this work.
The Eligibility policies and approval policies can technically be configured by updating the Eligibility dynamoDB table directly and specifying the appropriate attributes.

@tawoyinfa am I correct in saying that this feature is to enable the programatic access outside of group based authorization?

If so, is there any sort of estimated time frame on this feature?

Knowing that the eligibility and approval policies can be managed by updating the database directly will help our team in the short term.

Currently, we are also directly creating/updating the policies in the database in our Step Functions. The PK ID should correspond to the group ID.

   data = {
        "id": group_id,
        "__typename": "Eligibility",
        "accounts": [{"M": {"name": {"S": account_name}, "id": {"S": account_id}}}],
        "approvalRequired": False,
        "createdAt": current_time,
        "duration": "8",
        "modifiedBy": "team@org.com",
        "name": f"{account_id}-Admin",
        "ous": [],
        "permissions": [
            {
                "M": {
                    "name": {"S": team_permission_set_name},
                    "id": {"S": team_permission_set_id},
                }
            }
        ],
        "type": "Group",
        "updatedAt": current_time,
    }

    try:
        response = ddb_client.put_item(
            TableName=team_table_name,
            Item={
                "id": {"S": data["id"]},
                "__typename": {"S": data["__typename"]},
                "accounts": {"L": data["accounts"]},
                "approvalRequired": {"BOOL": data["approvalRequired"]},
                "createdAt": {"S": data["createdAt"]},
                "duration": {"N": data["duration"]},
                "modifiedBy": {"S": data["modifiedBy"]},
                "name": {"S": data["name"]},
                "ous": {"L": data["ous"]},
                "permissions": {"L": data["permissions"]},
                "type": {"S": data["type"]},
                "updatedAt": {"S": data["updatedAt"]},
            },
        )
        LOGGER.info(f"Item added successfully: {response}")
    except ClientError as err:
        LOGGER.error(f"Error putting item: {err}")

@lvthillo Thank you for sharing the information about the ability to automate policies by hitting the database directly. Our team will likely use this method in the short term, but I will wait until there is a method to authenticate with the API for releasing the terraform provider.

Having to change authentication methods would cause a breaking change. So I will likely just wait to release the provider until the authentication methods for Machine access have been solved.

@tawoyinfa I have opened a PR that should close out this issue and enable a method of secure machine authentication. Please let me know when you have had a time to review. I will also be working on getting some documentation added for this new method.