aws-cdk: sagemaker: can not launch studio app for a SSO user that is created with CDK

Describe the bug

I’d like to create sagemaker user and app in a stack along the sagemaker domain using the SSO users in the account. While the stack is deployed without any error, the attempts to open the studio app from the console, yield the following error:

Access Denied. Please check if user is assigned to Studio Domain [...] and SSO Application [Amazon SageMaker Studio (...)] is Active.

Expected Behavior

The studio app should create jupyter server without any issues.

Current Behavior

The user and app are created with the stack successfully, but upon accessing the jupyter server via user’s profile in the console, it fails with the above mentioned error.

Reproduction Steps

Here’s the stack:

class SagemakerDomainUsersStack(Stack):
    def __init__(self, scope: Construct, construct_id: str, config: dict, **kwargs):
        super().__init__(scope, construct_id, **kwargs)

        domain = aws_sagemaker.CfnDomain(
            scope=scope,
            id="sagemaker-domain",
            auth_mode="SSO",
            default_user_settings=aws_sagemaker.CfnDomain.UserSettingsProperty(execution_role=config["execution_role"]),
            domain_name=config["domain_name"],
            subnet_ids=config["subnet_ids"],
            vpc_id=config["vpc_id"],
        )

        for user in config["users"]:
            user_profile = aws_sagemaker.CfnUserProfile(
                scope=scope,
                id=...,
                domain_id=domain.attr_domain_id,
                user_profile_name=user["aws_username"].split("@")[0].replace(".", "-"),
                single_sign_on_user_identifier="UserName",
                single_sign_on_user_value=user["aws_username"],
            )
            
            aws_sagemaker.CfnApp(
                scope=scope,
                id=...
                app_name="default",
                app_type="JupyterServer",
                domain_id=domain.attr_domain_id,
                user_profile_name=user_profile.user_profile_name,
            )

Configurations look like this:

vpc_id: ...
subnet_ids:
  - ...
  - ...
execution_role: ...
domain_name: ...
users:
  - aws_username: first.user@postnl.nl
  - aws_username: second.user@postnl.nl

Possible Solution

No response

Additional Information/Context

The role has access to sagemaker:CreateApp.
If the profile is created via the console (with or without the execution role for the user), the studio app works without the abovementioned issue and jupyter server opens successfully.

CDK CLI Version

2.59.0

Framework Version

No response

Node.js Version

v18.0.0

OS

Linux

Language

Python

Language Version

Python (3.10.8)

Other information

No response

About this issue

Original URL
State: open
Created a year ago
Reactions: 4
Comments: 16 (3 by maintainers)

Most upvoted comments

@jmeisele, I don’t think there’s anything to do for Terraform or CDK to call that API. The API is deprecated, you cannot find any implementation of it in boto3 or any other AWS SDK, so the only way that comes to mind would be to look up some very old version of some SDK (before the AssociateProfile call got deprecated) and see how it worked. If that’s successful, I’d try to implement a call to that API (if it’s even available publicly, still, which may not be the case) and just wrap that with (manually crafted) AWS Signature V4 and see if it works.

There’s a lot of ifs here, and even more places where things may fail because - officially, at least - the endpoint doesn’t exist.

I think we just have to wait for AWS / SSO Team to implement missing pieces in the new CreateAccountAssignment API.

mkielar on Aug 29, 2023

@pahud, we’re seeing the same issue when using terraform, AWS CLI and boto3. We also looked up things in CloudTrail, and we can see, that - when assigning users via AWS Web Console - there are additional events in CloudTrail, named AssociateProfile, which look more or less like this:

    ...
    "eventName": "AssociateProfile",
    "awsRegion": "eu-west-1",
    "sourceIPAddress": "188.114.87.11",
    "userAgent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/114.0.0.0 Safari/537.36",
    "requestParameters": {
        "accessorId": "9367087262-04261254-3711-4406-bf1c-bf9927e68ce2",
        "accessorType": "USER",
        "accessorDisplay": {
            "userName": "HIDDEN_DUE_TO_SECURITY_REASONS"
        },
        "directoryId": "d-9367087262",
        "directoryType": "UserPool",
        "instanceId": "ins-55299dee38867b69",
        "profileId": "p-046276c336a0b9c0"
    },

We can also see ListProfileAssociations events when navigating to Identity Center WebConsole and clicking through the “Application Assignments” section.

However, both AssociateProfile and ListProfileAssociations are supposed to be deprecated according to https://docs.aws.amazon.com/singlesignon/latest/userguide/security-authorization.html, and were replaced by CreateAccountAssignment and ListAccountAssignments API Calls respectively.

This looks like Sagemaker / SSO still internally use some old API Endpoints which are no longer available to external clients (including your own AWS CLI and boto3). And - what’s even worse - the new CreateAccountAssignment, ListAccountAssignments and ListInstances API calls don’t at all support “Application assignments”!

What’s even worse, is that:

CreateAccountAssignment requires specifying a PermissionSetARN, only supports ACCOUNT type targets, and must be executed on the AWS Account where SSO is configugured (that’s Root Account in our case)
Whereas it seems that the AssociateProfile is executed on the DEV Account, where we deploy SageMaker Studio, and somehow it is able to provision SSO Applications and SSO Application Assignments on the Root Account, even though the user doing this using WebConsole doesn’t have any permission to mess around on the Root Account! This looks like the WebConsole is doing some internal, cross-account magic that allows the user to create/modify/delete resources on RootAccount without explicit IAM Permissions!

mkielar on Jun 16, 2023

@hossein-jazayeri

Agree. This is definitely not an acceptable user experience. We have reported this internally to the relevant team. I will update here when I have any news. This is related to SageMaker with SSO and nothing CDK can do at this moment.

pahud on Mar 7, 2023

@mkielar received word from my AWS colleague, this is on the roadmap late 2023, Q1 2024

jmeisele on Aug 29, 2023

Can confirm that this is still happening. We would like to create a SageMaker domain and assign SSO users to the domain via IaC, but can not get it working without tinkering around in the console. Any updates from the relevant team?

l3ku on Aug 9, 2023

@mkielar @hossein-jazayeri @pahud keep an eye out for for the next terraform-provider-aws release. One of the output attributes is going to be the single sign on ARN for the Sagemaker domain. This can be combined with new resource aws_ssoadmin_application_assignment to assign to groups.

https://github.com/hashicorp/terraform-provider-aws/issues/34673 https://github.com/hashicorp/terraform-provider-aws/pull/34741

jmeisele on Dec 7, 2023