I have access to an AWS console through One Login, in which I'm assigned a role to do my business. I want to set up the CLI tool but since I don't have my own user credentials, I'm a little unclear on how to generate the access and secret access key. I don't have the ability to create a user, although that would definitely be a dumb way to go even if I could. All my Googling says to look it up from the user page or use AWS SSO, neither of which are an option for me
You can generate temporary credentials. But this is not possible if you already use temporary credentials afaik.
https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_use-resources.html#using-temp-creds-sdk-cli
Best case would be:
Ask your SysOps or DevOps engineer to provide you CLI credentials.
Related
I am confused about the use cases and advantages of STS. As per the documentation, it is to temporarily acquire a role to perform tasks within AWS which are not available for the IAM user or service. Please note that I am talking about programmatic access (NOT console access)
For example, an IAM user may not have S3 permissions. As per my understanding:
He can get temporary access key/token by contacting AWS STS and get access key and secret for S3.
With those temporary credentials, he can access S3.
My questions are:
To get temporary credentials from AWS STS, he still need his existing access token (permanent) and secret, right?
If his existing access token and secret are leaked, an attacker can still use it to first get temporary credentials from STS and then access S3, right? I understand that the attacker won't be able to directly access S3 using his permanent access token and secret.
I am trying to wrap my head around its correct use cases. I know that I'm confused, but maybe I'm thinking in loops.
Thanks in advance.
They don't so much "contact AWS STS and get access key and secret for S3". Rather, they call AssumeRole() on an IAM Role that has permission to access Amazon S3. Then, using the temporary credentials that are returned, they can access S3.
Your confusion seems to be mostly around the use-case for IAM Roles. I like to explain it by way of a story...
I am a Fire Warden in my office at work. If the Fire Alarm activates, I go to a cupboard, put on a red helmet, then walk around the office and direct people to the stairwell. Since the alarm is sounding and I'm wearing a red hat, people (mostly) do what I tell them. However, if it was a normal day with no alarm sounding and I wasn't wearing the red hat, and I asked them to exit the office via the stairwell, they would likely look at me strangely and ignore my request. The difference is that I assumed the role of a Fire Warden, which gave me extra permissions.
So, as a normal person, I can't order people out of the office. However, once I assume the role, I have extra permissions.
This is a good practice for IT systems, too. The Systems Administrator in your company probably has permissions in your AWS Account to do anything. However, it would be a bad practice for them to use an account with such powers on a day-to-day basis. Instead, their IAM User account should just have normal permissions but, if they want to do Admin-type stuff, they have the ability to Assume an Admin Role and then do powerful stuff. When they're finished, they should exit the role and keep being a normal user. This is much 'safer', since they can't accidentally do something powerful when they are a 'normal user'.
Amazon Security Token Service (STS) is also used to provide permissions to software running on Amazon EC2 instances. In this case, an IAM Role is assigned to the EC2 instance and the EC2 service 'assumes' the role on behalf of the instance. It then provides the temporary credentials via the EC2 Instance Metadata service. In this example, there was no IAM User that assumed the role. Instead, the EC2 service assumed it on behalf of the instance.
STS can also provide cross-account permissions. For example, an IAM User in Account A could call AssumeRole() on an IAM Role in Account B. If they have permission to do this, then they will be given temporary credentials that are associated with Account B. This is required because credentials from one Account can never be used to manage resources in another Account.
There are other reasons for using temporary credentials too, such as using MFA tokens, federated logins where there are no IAM Users, and reducing your own set of permissions.
I will try to extend and generalise the first answer. The example with the Fire Warden is good to understand, but I feel it needs some extension.
Generally the AWS STS is able to return role credentials based on other identity or role credentials (aws or other identity provider).
The original credentials can be either AWS credentials from the same account, another account, federated token (e. g. supported social networks) or even a custom identity broker.
see https://docs.aws.amazon.com/cli/latest/reference/sts/index.html
Common use cases:
privilege elevation - this is already mentioned, AssumeRole allows to become another role within the same or different aws account
authorization to aws resources for identities authenticated a other way (AD, SAML, OIDC,..), see services AssumeRoleWithSAML or AssumeRoleWithWebIdentity.
authorization to aws resources with custom authorization, see GetFederationToken.
To get temporary credentials from AWS STS, he still need his existing access token (permanent) and secret, right?
By default AssumeRole, the user needs to be authenticated and having permission to assume the role.
If his existing access token and secret are leaked, an attacker can still use it to first get temporary credentials from STS and then access S3, right?
yes
I understand that the attacker won't be able to directly access S3 using his permanent access token and secret
if you configure the S3 or IAM permissions that way
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.
My requirement is to access some AWS APIs from a mobile application(Written in flutter). Currently how I have done it is by creating an IAM user with only the permissions required and using the access credentials of that user I sign my APIs.
What I am looking to do is instead of storing these credentials with in my app. Is there a way to use some sort of sign in mechanism to obtain some credentials and use those for signing my APIs?
Update 1:
To add more context. This is purely a hobby project and mostly for personal use. And for my use case storing credentials with in application is more than enough. Anyway I have intention to publish it as an open source project and I want to add a better way to handle this. Currently am not storing any credential in my code but am adding it as a an ENV during build process.
I think I would be able to handle this if I create my own backend to generate temporary credentials. But if there is some other standard solution out there I would like to utilize that.
Storing credentials in an application is an antipattern, and AWS provides features that prevent the need for you to do so.
Two alternatives off the top of my head.
The most obvious of these is AWS IAM Instance Profiles. These permit you to bind IAM permissions to an EC2. Any application or service on this ec2 is then permitted to perform the actions permitted by the IAM profile bound to the Instance Profile.
If you are running your application in EKS, you can leverage IRSA to bind IAM permissions to a service-account in the EKS cluster.
I assume you're running your service on EC2, and that therefore the InstanceProfile approach is easiest.
I have been working for the past week using Access and Secret keys that I generated for connecting REST API to DynamoDB and AWS CLI, today I just got told by the offshore team that I am not supposed to use Access and Secret keys at all that I'm supposed to use IAM roles and I have been researching how to do that but I'm stuck, has anyone here ever had the same issue?
If everything was done the way you said it in the question and also in your comment reply to #stdunbar, it is impossible to do so, those are the purpose of both secret and access keys, i dont think your offshore team knows what they are talking about
There are methods to acquire STS session keys (like when you assume a role) from AWS. One solution is Hashicorp Vault, but this requires the infrastructure has been configured to allow this. There are other methods that use the webui session to generate an STS token.
Ask your offshore team what method you should use to get a role based access session token. You were probably used to the cli asking for Access Key ID and Secret Key. The session key will come in three parts instead of two. The session access key id will start with ASIA instead of AKIA; the session secret access key is the same as its static counterpart; the session token is a very long string.
The easiest way to set these are to edit the credentials file in .aws/credentials. If you use aws configure you won't be prompted to set the session token. you could use aws configure set for each of the parts, if you don't already have profiles set up in your credential file you can just edit the default credential profile.
source:https://docs.aws.amazon.com/cli/latest/reference/configure/index.html
The point that they're (correctly) making is that your application should not include explicit credentials.
Instead, the application should be configured in Elastic Beanstalk with an IAM role. When the application runs and uses an AWS SDK, the SDK will be able to retrieve temporary credentials from the Beanstalk environment that it is running on.
You can read more at Managing Elastic Beanstalk Instance Profiles.
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