is there a way to disable programmatic access for users Signing in using AWS SSO?
Is it possible to control the programmatic and console access using polices or Groups?
No, you cannot prevent users to login and deny the programmatic access, because once users sign-in they have option to get required details to access programmatically.
The permissions a user has through SSO can still be managed through AWS IAM (Identity and Access Management) groups and rols. The same permissions a user has through IAM in the AWS console can be used by the user when accessing AWS programatically throught the CLI or an SDK.
No permissions are required for a user to get a session token. The purpose of the GetSessionToken operation is to authenticate the user using MFA. You cannot use policies to control authentication operations.
Source
Therefore, I don't think that you can prevent a user from using access keys to get temporary session tokes for programmatic access.
Why do you want to prevent programmatic access for users and am I right assuming that you mean CLI and SDK access to AWS by programmatic access?
Yes, you can, but exactly how will be buried in the implementation details of your organization's SSO implementation. Your SSO's custom identity broker is in charge of mapping a particular user's AD credentials to an AWS IAM role, which may or may not have permissions to login to the CLI. Exactly which role a user gets needs to be controllable in the broker. Another way is to control access to the AWS access keys needed to use the CLI or SDKs. Your SSO users shouldn't have permission to generate their own keys. They should come from IT or should be a configurable feature of your SSO implementation. For example, in my organization, there are 2 links in the AWS portal; one for console access and one to display temporary access keys that can be copied into the bash environment or used with an SDK.
Related
I have an App client created for a Cognito User Pool. The client has an ID and secret generated. It is configured to use the Client credentials flow and has a custom scope defined. With that in place, I'm able to successfully exchange the creds for an Access Token, so far so good.
I would like to use AWS SDK to manage users (list, delete etc) in the User Pool with the server-side app client. Assuming I validated the granted token, how do I use it with AWS SDK to execute Actions I need? Is there a better way to manage User Pools from a server-side app?
If you look at Admin* level actions in the Cognito SDK (e.g. AdminDeleteUser), you will see it does not accept access tokens. It rather expects valid AWS developer credentials.
So what you probably want to do is to create an IAM role with appropriate permissions to manage the user pool (resource format: arn:aws:cognito-idp:REGION:ACCOUNT_ID:userpool/USER_POOL_ID) and let your server application assume that role. With correct permissions configured, you can call the AWS SDK directly.
You can find the list of available IAM actions here.
We have an external application resides outside of Amazon network and it needs to access our SQS and send message there, in order for our AWS resource to recognize the request from that application it needs to sign its request with the credentials of the IAM role we created, I'm wondering what is the best way for that external application to retrieve temp credentials from us? I have tried to implement it using Amazon Cognito but it looks like Cognito fits more in scenarios like user sign-up and sign-in with an User Interface, anyone has any suggestions? Thanks in advance.
To be able to obtain temporary credentials, you need a form of permanent credentials that can access (or generate) the temporary credentials.
Given your situation, you might consider creating an IAM User in your account and giving those credentials to the third-party. Grant the appropriate permissions to those credentials and they can use them directly with Amazon SQS.
Or, if you'd rather not give IAM credentials to third-parties, you could ask them to create an AWS account and an IAM User. You could then grant their IAM user access to the Amazon SQS queue.
Another option is that the third-party could access an application or API that you provide. Once they authenticate, you can provide temporary credentials created with the Security Token Service. Cognito would be an option for performing this authentication and it can also provide credentials for an associated IAM Role, thus giving them access to the Amazon SQS queue.
At my employer, we have an AWS account that uses SAML 2.0 to federate in your user access from the company SSO login to the AWS console. The net effect is that everyone has admin access. Is there a way to place federated users into different IAM groups, thereby giving least privilege access?
The answer we came up with is that all federated users would have very limited access to the console with no programmatic access. Then, create separate IAM users for everyone for programmatic access (no console login) and to place these separate users into IAM groups with varying access. Would this method be considered best practice or is there a better way to accomplish what we would like to do in this case?
The best practices is to use groups to set permissions (policies) for each class of user.
Grant users SSO access to AWS accounts in your organization by
selecting the AWS accounts from a list populated by AWS SSO, and then
selecting users or groups from your directory and the permissions you
want to grant them.
AWS Single Sign-On
Your SSO SAML 2.0 provider should be able to pass role information to AWS at sign-in. You can then have corresponding IAM roles setup in AWS.
We use Azure AD for SSO and set it up using this example: https://blog.flux7.com/aws-best-practice-azure-ad-saml-authentication-configuration-for-aws-console
Basically you create Azure AD Security Groups and map them to IAM roles.
I am developing a web application with two mobile(Android & iOs) based applications of the same. Currently the files uploaded are open to all, which in terms means that anyone with the direct image link can open it using a web browser.
How can I protect or limit the file access to the users of my mobile applications or web application ?
NB: As a beginner, I am not sure about the configuration details to be provided along with question, If I need to give more details on my s3 config. please specify it, I can add it to the s question to make the question more meaningful, so sorry for the inconvenience.
I think an easier approach than pre-signed urls would be to use Amazon Cognito to provide access to AWS resources to your trusted applications, even to unauthenticated users.
To do this you would create an Identity Pool for your application (just need one pool for all 3 of your clients) and then configure it so that when a client provides a valid Identity Pool Id they can assume an IAM role with permissions to access AWS resources.
Then you control what S3 bucket permissions the IAM role they assume would have - you could allow unauthenticated users access to read the S3 objects, or force them to create accounts to be able to read/write to S3 buckets (this is very easy with Cognito - users can sign up with facebook, gmail, their own email, etc.)
There's a step-by-step guide here for setting up an identity pool with Cognito, and then allowing unauthenticated users to assume an IAM role that can access the contents of an S3 bucket
The above causes the same set of permissions for all guest user accounts - that have assumed an IAM role through Amazon Cognito by identifying themselves as part of an identity pool.
edit: I should point out that if you authenticate via Cognito, you'll need to access the S3 bucket through the S3 Transfer Manager from the AWS SDK
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