I'm working with developers who have recently moved over to Google Workspace for business communications. They are relying on Jenkins for build automation. They also have team-limited AWS console access, access to CloudWatch logs and SSH access to some EC2 development hosts running docker containers. We are considering using the Google account for federated sign-on to Jenkins and to AWS SSM Systems Manager, which will replace the SSH host access. Access will be restricted by team, so some form of group-management is important.
For the Jenkins access, I have followed this document to use Google federation and Amazon Cognito: https://www.tech-notes.net/jenkins-login-with-cognito-in-aws/
The groups can be added into AWS Cognito groups within the userpool and mapped into Jenkins oic-auth plug-in as "cognito:groups".
For the SSM Session Manager access, we could use identity federation for a Google login into the AWS account ... and then user IAM groups and IAM policies. However, we would already require groups management within the Cognito userpool (i.e. double the admin). So could either userpools provide the SSM access permissions? Or could the users present in IAM somehow be present for Cognito too?
We would also consider the alternative solution of not using Google federation if the AWS IAM user accounts could be mapped to log into Jenkins using AWS credentials ... but I can't see how this would work.
Many thanks.
Related
So I think that the simplest solution is my problem is to use AWS for everything but I wanted to understand what is possible:
I understand that IAM roles can be associated with an AWS service such as EC2 or Lambda so that an application/function running within that service can retrieve credentials to sign API requests to other AWS services.
I have a previous application running on Heroku and using Amazon S3. Currently I have an IAM user set up for this application which signs requests to the AWS API using the access keys associated with the IAM user account. I think that best practice is to use an IAM role rather than a user for application source code AWS API calls, however is it possible to set this up for the application hosted outside of AWS or would I need to migrate the application to AWS EC2 in order to use IAM roles?
It doesn't matter where the application is hosted but to assume an IAM role you will need IAM credentials (chicken and egg). Typically you would design a secure way for your app to retrieve these base credentials. This is one disadvantage of running your compute outside of AWS (because it can't automatically assume an IAM role).
One option would be to create an IAM user whose only permissions were to be able to assume a given IAM role. Supply those IAM user credentials to your application, outside of AWS, securely and have the application assume the IAM role, ideally with an ExternalId that itself is also securely stored and securely retrieved by your application. Additionally, you can manage access to the IAM role, for example defining which principals can assume the role, and under which conditions.
AWS announced a new feature AWS IAM Anywhere that should help if you need to avoid using access/secret keys. It's more complicated but follows security best practices.
AWS Identity and Access Management (IAM) now enables workloads that
run outside of AWS to access AWS resources using IAM Roles Anywhere.
IAM Roles Anywhere allows your workloads such as servers, containers,
and applications to use X.509 digital certificates to obtain temporary
AWS credentials and use the same IAM roles and policies that you have
configured for your AWS workloads to access AWS resources.
and more here:
create a trust anchor where you either reference your AWS
Certificate Manager Private Certificate Authority (ACM Private CA) or
register your own certificate authorities (CAs) with IAM Roles
Anywhere. By adding one or more roles to a profile and enabling IAM
Roles Anywhere to assume these roles, your applications can now use
the client certificate issued by your CAs to make secure requests to
AWS and get temporary credentials to access the AWS environment.
AWS Announcement: https://aws.amazon.com/about-aws/whats-new/2022/07/aws-identity-access-management-iam-roles-anywhere-workloads-outside-aws/
User Guide:
https://docs.aws.amazon.com/rolesanywhere/latest/userguide/introduction.html
From Heroku docs:
Because of the sensitive nature of your S3 credentials, you should never commit them to version control. Instead, set them as the values of config vars for the Heroku apps that will use them.
Use the heroku config:set to set both keys
heroku config:set AWS_ACCESS_KEY_ID=xxx AWS_SECRET_ACCESS_KEY=yyy
Adding config vars and restarting app... done, v21
AWS_ACCESS_KEY_ID => xxx
AWS_SECRET_ACCESS_KEY => yyy
The above is in line with AWS's own best practices for managing AWS access keys, specifically not embedding access keys directly in code.
You can't use IAM roles in the sense that it is picked up automatically by AWS, outside of AWS, without specifying credentials specifically.
Your next best option is environment variables (as detailed above), specifying the access key ID and secret access key for a user with a role granting the least privilege required for the files they need to read from S3 e.g. specific bucket name, specific files, even specific IP addresses if possible, etc.
I was wondering if I could use AWS organisation and AWS SSO to provide access to AWS services to someone without an AWS account.
Is it possible using the above mentioned services or some other way?
AWS SSO could be used which would utilise the credentials of whatever Identity Provider you can connect to SSO i.e. OKTA/Active Directory etc.
With that setup an AWS account would not be provided as their access would be assumed through a permission set/role you create, and they can consume AWS services
https://docs.aws.amazon.com/singlesignon/latest/userguide/manage-your-identity-source.html
My goal is to use Okta SSO integrated with AWS SSO to integrate all user Sign-in and permission management for AWS resources from the Okta, using accounts configured on Okta.
I also want it so that each user on Okta has their own Amazon Workspace Windows instance using their Okta credentials.
I currently have a Simple AD (Directory Service) configured on the AWS account, exclusively for Amazon Workspaces access.
Is this a possible goal that can be achieved using OKta, AWS SSO and Directory Service? After going through each of their documentations I am still not clear if these services have the capability to integrate this way.
Any Advice would be appreciated.
There are two topics in this question.
AWS SSO:
There is a standard integration in the AWS Documentation.
https://docs.aws.amazon.com/singlesignon/latest/userguide/okta-idp.html
AWS WorkSpaces:
You mentioned that you use currently SimpleAD, in case you want to switch the IdP for your WorkSpaces you should be aware that you need to re-provision the WorkSpaces. I've not as much experience with OKTA, but I think there are two options.
In case you've already a Active Directory you should be able to integrate it with WorkSpaces (AD Connector or AWS Managed AD with forest trust)
https://docs.aws.amazon.com/directoryservice/latest/admin-guide/ms_ad_tutorial_setup_trust.html
https://docs.aws.amazon.com/directoryservice/latest/admin-guide/directory_ad_connector.html
In case there is no pre-existing AD, you should be able to sync the users with a AWS Managed AD.
https://help.okta.com/en/prod/Content/Topics/Directory/ad-agent-integrate-existing.htm
OKTA MFA integration for WorkSpaces:
https://aws.amazon.com/blogs/desktop-and-application-streaming/integrating-okta-mfa-with-amazon-workspaces/
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.
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).