How does one make AWS SageMaker available to people outside their organization? - amazon-iam

I am setting up SageMaker for a group outside my organization, and wondering how I provide access to SageMaker Studio (and any dependent AWS resources SageMaker would use) to these users.
The idea is to have then use SageMaker studio to do train and test models.
Ideally, it would be great if I simply send them a link where they sign in, and are then granted access to SageMaker hosted from my AWS account.
I believe to grant temporary access I need to attach a role to a group of users, and also attach a policy to this group, them finally associate this role with SageMaker. But how do I then create a link to SageMaker so these users can sign in?
The other option would be to set this up using cross-account access, since those I want to give access to also have their own AWS account. But again, how does one generate a link to direct these users to the SageMaker on my AWS account?
There appears to be 2 options, as per SageMaker Onboarding:
AWS SSO authentication
access to Studio via unique sign-in URL that directly opens Studio
sign in with their SSO credentials
organizations manages members in AWS SSO instead of Studio
can assign multiple members access to Studio at the same time
IAM authentication
sign in through the SageMaker console
must add and manage members manually one at time using the Studio Control Panel
I don't understand the 2nd approach, since wouldn't this mean users would have to sign-in as root to the console anyway and then have full access. I could edit the policy attached to IAM users, but this begs another question:
...does SageMaker come pre-baked with policies that include its dependent AWS services? For example, SageMaker will use S3 for storage and EC2 for processing; do I need to set these individually in the policy, or can I simply use a SageMaker policy, which will include all those dependencies by default?

First of all, you can generate "disposable" (called pre-signed) URLs which can be used for accessing SageMaker Studio User Profiles without any AWS credentials. These URls can be valid for max 5 minutes and can be generated with a single AWS API call.
One approach to provide Studio access to your users is to set up a service which can authenticate your Studio users and then calls the CreatePresignedDomainUrl SageMaker API method to sends back the generated pre-signed URL to the user.
Alternatively, you can use AWS SSO as well, which can do most of the heavy lifting for you, especially if you'd like to integrate with a single sign-on service. AWS SSO integrates with SageMaker Studio and you can assign Studio user profiles to your onboarded users. Your users then can go through your single sign-on service and can launch the Studio without logging into the AWS Console.
An another approach is to use IAM Federation where you basically provide access to the AWS API and/or to the Console to your users which authenticated by an (external) identity provider. Federated users can assume specific roles to operate with the AWS API or the Management Console. For accessing SageMaker Studio, users just need to have the CreatePresignedDomainUrl access policy which allows them to create the pre-signed URL by themselves. If you want to isolate your SageMaker user profiles and ensure each federated user can access just those user profiles which are assigned to them, please see the following blog post for more information.
And finally, please note that, once the user has logged in to Studio, the Execution Role configured for the specific user profile will determine what the Studio user can access and is able to do (e.g. spinning up SageMaker training jobs, deploying models, accessing S3, etc). Thus, you don't need to set up these policies for your IAM users or roles used by the federated users.

Related

AWS: To Role or not to Role?

From AWS docs:
When to Create an IAM User (Instead of a Role)
...
You want to use the command-line interface (CLI) to work with AWS.
When to Create an IAM Role (Instead of a User)
- You're creating an application that runs on an Amazon Elastic Compute Cloud (Amazon EC2) instance and that application makes requests to AWS.
- You're creating an app that runs on a mobile phone and that makes requests to AWS.
- Users in your company are authenticated in your corporate network and want to be able to use AWS without having to sign in again—that is, you want to allow users to federate into AWS.
But it seems like companies heavily use roles for everything:
Role for groups by creating roles with specific policies and creating custom policies to apply to groups.
Assume role to use the CLI.
Switch role to use different accounts.
Is that excessive or real work based solution?
Is that excessive or real work based solution?
Based on my own experience with AWS, heavily using roles is a real work based solution because, in my company, we use only roles to give access to users (yes, we have 0 users registered in your AWS environments). I'll list the reasons why we chose this way:
We are using AWS Control Tower.
This service enables AWS Organizations with at least 3 AWS accounts to manage your organization. It'd be a mess with we had to create a user for each AWS account. Also, AWS Control Tower enables AWS Single Sign-On.
We're using AWS Single Sign-On.
This service correlates multiples AWS accounts with multiples roles with multiples users. Description:
AWS Single Sign-On (SSO) is a cloud SSO service that makes it easy to centrally manage SSO access to multiple AWS accounts and business applications. With just a few clicks, you can enable a highly available SSO service without the upfront investment and on-going maintenance costs of operating your own SSO infrastructure. With AWS SSO, you can easily manage SSO access and user permissions to all of your accounts in AWS Organizations centrally. AWS SSO also includes built-in SAML integrations to many business applications, such as Salesforce, Box, and Office 365. Further, by using the AWS SSO application configuration wizard, you can create Security Assertion Markup Language (SAML) 2.0 integrations and extend SSO access to any of your SAML-enabled applications. Your users simply sign in to a user portal with credentials they configure in AWS SSO or using their existing corporate credentials to access all their assigned accounts and applications from one place.
Please, check out some features offered by this service. There are a lot of benefits using roles instead of users. In my point of view, with AWS SSO, AWS itself facilitates the use of roles.
The only disadvantage I found is that every time I need to use AWS CLI, I need to access AWS SSO portal, copy the credentials and paste in my terminal because credentials expires after some time. But in the end, this disadvantage is small compared to the security that this process offers - if my computer is stolen, AWS CLI couldn't be accessed because of credentials expiration.

Create AWS IAM users based on e-mail domain

I am setting up an AWS Account, the account will be used by an organization of employees for EC2 use/experimentation. Obviously, I do not want to distribute the root login info or set up one single IAM user for everyone to use. Unfortunately, I do not have the time to manage creating individual IAM users for everyone on a regular basis.
So, is there a way to auto-create IAM users based on a given email's domain on their first login attempt? The users should have read-only roles to begin, then an Administrator could give more roles as needed to each user. I am open to suggestions, perhaps lambda functions or linking to an identity provider?
Keep in mind that these new IAM users need to have access to the AWS Management Console, this is not necessarily intended for login to applications hosted on AWS.
Update:
Moving forward using this AWS Management Console Federation Proxy Sample found in Amazon's code reference, using with Microsoft Exchange hosted email.
If your existing identity provider supports SAML2 Federation, you can set it up to login to the AWS Management Console.
For more details refer Enabling SAML 2.0 Federated Users to Access the AWS Management Console.
Else you can implement a custom Federation Broker to return an URL to the user, after they authenticate with their corporate credentials.
For more details refer Creating a URL that Enables Federated Users to Access the AWS Management Console (Custom Federation Broker).

AWS access keys (for CLI authentication, etc..) for users from a SAML identity provider, or AD connector?

I've been looking in to getting the AWS (web) console hooked up to an AD or ADFS setup for managing users. It was reasonable easy to get working with a SAML Identity Provider in IAM and some existing ADFS infrastructure.
The problem is that users that authenticate that way, as opposed to normal AWS user accounts, don't have any way to have associated access keys so far as I can tell. Access keys are a key concept for authenticating stuff such as the AWS CLI, which needs to be tied to individual user accounts.
What are the workarounds to allow a user authenticated via a SAML identity provider to still be able to easily use the aws CLI? The only thing I've come up with to far is some hacky crap that would proxy the aws cli command, request temporary 1-hour credentials from the aws STS service, put them in the aws credentials file, and forward the command to the normal AWS cli. But, that makes me want to throw up a little bit; plus, I have no idea if it would work if a command took over an hour to complete (large s3 uploads, etc..)
Suggestions? I would try the official Directory Service AD connector, but my understanding is users still just assume IAM roles and would ultimately have the same problem.
https://github.com/Versent/saml2aws was created to address this, and has a vibrant open source community behind it.
I've had success with aws-adfs for AWS CLI via ADFS
The repo owner is currently adding support for DUO MFA as well.
It works by authenticating the user to the same page you'd use for console access then scraping the roles available. You choose a role and then aws-adfs sets the default user to the credential set needed for sts access.
After the default user is set you can cli like normal: aws s3 ls
https://github.com/venth/aws-adfs

Amazon Web Services read-only account?

Is there an option to grant read-only access to an Amazon Web Services (AWS) account?
What I'd like to achieve is to be able to see instances and configurations without having to log in as a user who has administrative permissions to avoid accidental changes.
No. An AWS Account cannot be made "read-only".
However, you can create a User in Identity and Access Management (IAM) and assign them "Read Only" permissions, which means they can interact with AWS but cannot change anything. However, this would still require that they login or at least use a set of credentials with calling the API or using the Command-Line Interface (CLI).
If your main goal is to avoid accidental changes, try this:
Create a User in IAM who has minimal permissions (eg read-only, and probably also permissions to create new resources such as buckets and instances)
Create a Role in IAM that has elevated permissions
Setup the User with the ability to "assume" the Role within the web browser
This way, the User won't have 'dangerous' permissions unless they specifically request it. A visual indication then shows when they are using this alternate role (which can also grant access to a different AWS Account).
For details, see:
Blog: Cross-Account Access in the AWS Management Console
Article: Enable a New Feature in the AWS Management Console: Cross-Account Access

Amazon Web Services Developer User Permissions

I have an Amazon Web Services account which will be used to host the backed of an app. The backend uses PHP/MySQL and will most likely use an EC2 instance and RDS. I have my own account which has access to everything. I need to create an account for a developer to put the backend on AWS but I don't want them to have access to anything except what they need. I know how to create IAM users and Groups but I don't know which permissions to grant the developer. Under Select Policy Template there is a Power User template, is that good for a developer? Has anyone done this before?
The Power User Access template in AWS Identity and Access Management (IAM) grants permission to do ANYTHING except using IAM. A user with this permission can view, create or remove any resources in your AWS account, but they could not create new users or modify any user permissions.
It is recommended that you only give people the least amount of privilege required to use AWS, so that they do not intentional nor accidentally do something unwanted. However, if you do not have enough knowledge of AWS to know what functionality is required, you will most likely need to trust the developer to configure the system for your needs.
A few tips:
Only give them access via an IAM User -- never give them your root credentials
If you don't know what permissions are required, then "Power User" is at least safer than "Administrator" since they cannot edit IAM settings
When they have completed their work, revoke their access so they cannot create any more AWS resources
Determine whether you also wish to revoke access to the EC2 instances (you'll have to do this on the instances themselves)
You may need to define some roles that will be used with Amazon EC2 -- these are defined in IAM, so the developer will not have permission to create the roles himself
Ask the developer for documentation of what he has deployed
Turn on Detailed Billing to identify what AWS charges you are receiving and check them against the documentation
Turn on CloudTrail to activate auditing of your account (it is activated per-region)
Alternatively, you could do all the AWS configuration (launching an EC2 instance, creating the database) and only let the developer login to the EC2 instance itself. That way, they would not need access to your AWS account.