Can we use AWS Lambda for cross account activity. For example, I want to store a Parameter in SSM Parameter store in multiple AWS Accounts. Imagine I have a Master AWS Account which has access to all other AWS Accounts. Now can I write a python script for storing the parameter and make use of AWS LAMBDA to perform this.
Yes Definitely. AWS services are by default explicitly denied access from anywhere. Thats where AWS IAM (Identity & Access Management) came into the picture.
Delegate Access Across AWS Accounts Using IAM Roles
Let say you have a master account that has a services needed by multiple accounts. The first thing you will do is provision the resource from that master account and then by doing so you are applying right policies that will give an access to the other accounts.
Lastly, some other services are protected by layers of protection such as NACL's for network layer protection and Security Groups for application layer protection. For this services that are protected by layers mentioned, you simply just need to check if these layers accepts and send traffic from the application ports that you're are using.
e.g. EC2 Security Group - Ingress Rule: 80, 443 0.0.0./0
Imagine I have a Master AWS Account which has access to all other AWS Accounts.
This is usually setup by AWS Organizations. It helps with management and governance of all your accounts in a unified way.
System manager, which include Parameter store has special provisions for working with AWS Organizations:
You can synchronize operations data across all AWS accounts in your organization by using Organizations and Systems Manager Explorer.
The generall cross-account concepts have been addressed by other answer.
Related
We would like to access the aws xray which is deployed in multiple regions like Europe, US-east and US-west.
I would like to access these using access key id and secret access key id and maybe session token as well.
I want to know is it necessary to specify the region while accessing the aws xray resources of these regions.
What if I don't specify the region and just specify the keys to access the AWS resource (aws xray); will we be able to access those?
Customer-centric exact issue:
We have to talk to a customer, he is going to say that he has deployed AWS xray in three regions.
We usually access the Customer's resource and get data and do some processing.
So What details we should say to the customer that we would need from him ?
Thanks in advance.
You can create a role that users in other accounts or people outside of your organization can use to access your resources. You can specify who is trusted to assume the role. For services that support resource-based policies or access control lists (ACLs), you can use those policies to grant people access to your resources.
In case you need to provide access to an externally authenticated users (identity federation): https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_federated-users.html
AWS X-Ray traces are stored in specific regions as configured on X-Ray Daemon or the AWS managed services. If you want to use X-Ray APIs to send or fetch traces, you'll have to provide the region as well.
Are there any specific X-Ray APIs/Resources you're looking to use?
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.
I am in the early stages of writing an AWS app for our users that will run our research algorithms using their AWS resources. For example, our code will need to spin up EC2 instances running our 'worker' app, access RDS databases, and create access SQS queues. The AWS Java SDK examples (we are writing this in Java) use a AwsCredentials.properties file to store the Access Key ID and Secret Access Key, which is fine for examples, but obviously not acceptable for our users, who are would be in essence giving us access to all their resources. What is a clean way to go about running our system on their behalf? I discovered AWS Identity and Access Management (IAM) which seems to be for this purpose (I haven't got my head around it yet), esp. Cross-account access between AWS accounts. This post makes it sound straightforward:
Use the amazon IAM service to create a set of keys that only has
permission to perform the tasks that you require for your script.
http://aws.amazon.com/iam/
However, other posts (e.g., Within IAM, can I restrict a group of users to access/launch/terminate only certain EC2 AMIs or instances?) suggest there are limitations to using IAM with EC2 in particular.
Any advice would be really helpful!
The key limitation with regards to RDS and EC2 is that while you can restrict access to certain API actions there are no resource level constraints. For example with an IAM S3 policy you can restrict a user to only being able to perform certain actions on certain buckets. You can write a policy for EC2 that says that user is allowed to stop instances, but not one that says you can only stop certain instances.
Another option is for them to provide you with temporary credentials via the Security Token Service. Another variant on that is to use the new IAM roles service. With this an instance has a set of policies associated with it. You don't need to provide an AwsCredentials.proprties file because the SDK can fetch credentials from the metadata service.
Finally one last option might be consolidated billing. If the reason you are using their AWS resources is just because of the billing, then setup a new account which is billed from their account. The accounts are isolated from each other so you can't for example delete their instances by accident. Equally you can't access their RDS snapshots and things like that (access to an RDS instance via mysql (as opposed to the AWS api) would depend on the instance's security group). You can of course combine this with the previous options - they could provide you with credentials that only allow you to perform certain actions within that isolated account.