In Google Cloud Compute Engine, OS Login is really useful for having multiple users share the same instances on one file server. In a nutshell, it automatically adds the user to the instance. In AWS, I see similar resources, but it looks like you have to do it manually for each instance, and for each user. Is there a way to have this done automatically in AWS EC2?
Thanks!
Automatic Linux account lifecycle management and Fine grained
authorization using Google Cloud IAM
I did not use os login but the link you provided and their main feature is most similar to OpsWork of AWS like allow the user to ssh and restrict the access of each user and provide ssh access to IAM user.
To authorize SSH for an IAM user similar to OS feature (Fine grained authorization using Google Cloud IAM )
In the AWS OpsWorks Stacks navigation pane, click Permissions.
Select SSH/RDP for the desired AWS Identity and Access Management
(IAM) user to grant the necessary permissions. If you want to allow
the user to use sudo to elevate privileges—for example, to run agent
CLI commands—select sudo/admin also.
Importing Users into AWS OpsWorks Stacks is similar to OS login feature (Automatic Linux account lifecycle management)
Administrative users can import IAM users into AWS OpsWorks Stacks;
they can also import AWS OpsWorks Stacks users from one regional
endpoint to another. When you import IAM users to AWS OpsWorks Stacks,
you import them to one of the AWS OpsWorks Stacks regional endpoints.
If you want an IAM user to be available in more than one region, you
must import the user to that region.
Unix IDs and Users Created Outside AWS OpsWorks Stacks is similar to Ability to import existing Linux accounts
AWS OpsWorks assigns users on AWS OpsWorks Stacks instances Unix ID
(UID) values between 2000 and 4000. Because AWS OpsWorks reserves the
2000-4000 range of UIDs, users that you create outside of AWS OpsWorks
(by using cookbook recipes, or by importing users into AWS OpsWorks
from IAM, for example) can have UIDs that are overwritten by AWS
OpsWorks Stacks for another user. This can result in users that you
have created outside of AWS OpsWorks Stacks not showing up in data bag
search results, or being excluded from the AWS OpsWorks Stacks
built-in sync_remote_users operation.
So I think OpsWork is the best choice for you if we compare this with Os login of Google cloud.
There are lot of more feature of OpsWork but in context of Oslogin that seems similar to me. you can further explore here.
opsworks-security-users-manage-import.html
workinginstances-ssh
configuration-management-with-aws-opsworks
Take a look at EC2 Instance Connect.
you can control SSH access to your instances using AWS Identity and
Access Management (IAM) policies as well as audit connection requests
with AWS CloudTrail events. In addition, you can leverage your
existing SSH keys or further enhance your security posture by
generating one-time use SSH keys each time an authorized user connects.
Related
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.
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.
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 have a scaling group of several EC2 instances.
I have API keys which I would like to distribute to the instances using round-robin.
How can I code the instances to get the credentials once they go live?
Is there an AWS service for that?
It is not AWS credentials which could be solved by defining IAM Roles.
Thanks
Use "user data" option when you start your EC2 instance, You can run the bash script.
I recommend the following step.
1-put your cred or other shared information to S3 or dynamoDB.
2-write script to read and setting this data when your EC2 was starting.
The closest thing AWS has to this is called IAM Roles. A role includes a set of IAM permissions (like an IAM user). When you start a VM, you can set the role of the VM. The VM can then call the AWS API and get temporary credentials that give it access to the services that are defined in the IAM role.
See here for more details:http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/iam-roles-for-amazon-ec2.html
This does not exactly meet your requirement for round-robin credentials distribution. But it might be a better option. IAM roles are as secure a method of distributing credentials to EC2 instances as you can get.
AWS now provides two services that could be used for that purpose:
The Secrets Manager would seem to be the most fitting, but does cost money from the start.
The Parameter Store is also an option and is free for up to 10k parameters.
We have multiple AWS accounts (about 15-20), one AWS account per client that we are managing, each account having VPC having dedicated setup of instances. Due to regulatory requirements all accounts needs to be isolated from each other.
What is the best way to manage account credentials for these AWS accounts? Following is what I am thinking
-For any new client
Create a new AWS account
Create AWS IAM roles (admin, developer,
tester) for newly created account using cloudformation
Using master
AWS account, assume roles created in step 2 to access other
accounts.
Is this the right approact to manage multiple accounts?
Thanks in advance.
Facilitating IAM Roles is a very common and (I think) the right approach to manage authentication for multiple accounts indeed, AWS has just recently released resp. updates that greatly help with this, see Cross-Account Access in the AWS Management Console:
Many AWS customers use separate AWS accounts (usually in conjunction with Consolidated Billing) for their development and production resources. This separation allows them to cleanly separate different types of resources and can also provide some security benefits.
Today we are making it easier for you to work productively within a multi-account (or multi-role) AWS environment by making it easy for you to switch roles within the AWS Management Console. You can now sign in to the console as an IAM user or via federated Single Sign-On and then switch the console to manage another account without having to enter (or remember) another user name and password.
Please note that this doesn't just work for the AWS Management Console, but also with the AWS Command Line Interface (AWS CLI), as greatly explored/explained in by Mitch Garnaat in Switching Roles in the AWS Management Console and AWSCLI.
Furthermore, Mitch has followed up with a dedicated new tool 'rolemodel' to help with setting things up pretty much like you outlined, which you might want to evaluate accordingly:
Rolemodel is a command line tool that helps you set up and maintain cross-account IAM roles for the purpose of using them in the new switch role capability of the AWS management console. These same cross-account roles can also be used with the AWSCLI as described here.