I am in process to use prometheus cloudwatch exporter which can be used for monitoring various AWS accounts. I seen lot of documentation about configuring single IAM user (which are not programmetic) for cross account access but unable to find steps for configuring programmetic user to access cloudwatch across various account.
it will be great if someone can provide me pointers for same
You cannot really have a single IAM role being used cross accounts. What you really need is to create an IAM role that can be assumed by a different user account.
Below link would be helpful in defining a role that can be assumed by a different account:
https://docs.aws.amazon.com/IAM/latest/UserGuide/tutorial_cross-account-with-roles.html?shortFooter=true#tutorial_cross-account-with-roles-2
To utilise the cloudwatch exporter, you need to allow the exporter to assume the role in a similar way. You can create these roles quite easily using coding too. Comment with further details on what you need, will help out
Related
In the spirit of providing least privilege permissions I often find myself hunting down required permissions to complete a specific task or providing others with access. Access denial messages in AWS are usually pretty good and list the required permissions. However other times the error message can be vague, especially when one service is dependent on another. Is there a better way than trying to complete an action and granting required permissions one by one? Does a list or some sort of tool exist?
AWS now has AWS Access Analyser that can be used to generate IAM policies based iam user/roles.
Here is the documentation: https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-policy-generation.html
You can also use AWS CLI as well to generate policies based on IAM activity:
aws accessanalyzer start-policy-generation --policy-generation-details
and then, get the generated policies:
aws accessanalyzer get-generated-policy --job-id <>
another way, you can use user's access activity from AWS console and see what that user has been using and not using, and on basis of that you can create your policies.
Let's assume in current AWS organization we have 2 developers accounts. From what I found it is a good practice to create a separate AWS account per environment and give access to these resources.
My question is:
What is the best way to share access to the resources (e.g. EC2, EKS, EFS) for multiple developers? Now I see only these two options:
Create a separate AWS account for each developer and allow to access some resources by applying roles to that developers AWS accounts.
Within a root account of each AWS environment create a IAM user account for each developer and from that point manage permissions by policies and user groups.
Please let me know. I appreciate any type of help! :)
You should setup AWS SSO. Either integrated with your existing identity provider, or using the built in user system.
https://docs.aws.amazon.com/singlesignon/latest/userguide/what-is.html
This will allow you to create permission sets. Then, you can assign permission sets to users in particular accounts. This will create a role in the account which the users can assume
I have users that have been added by other admins in my AWS account. I am afraid that these users might get deleted by other people.
Is there a way to add a description to an IAM user?
I don't see any way to add description/tag when you create an IAM user. One suggestion is to create a IAM group for each admin and add the user to the admin's group when a user is created/added. You can have group(s) with no policy attached.
There is currently no way to add a description to a user. There are a number of better ways to solve your core issue however. Some of the IAM Best Practices specific to your use case include:
Use AWS Defined Policies to Assign Permissions Whenever Possible - AWS-managed policies are designed to support common tasks, such as deleting and creating users. Assign these policies to the users that need them.
Grant Least Privilege - Granting only the permissions required to perform a task. Determine what users need to do and then craft policies for them that let the users perform only those tasks. This is probably the most important factor in preventing users from being deleted accidentally.
Monitor Activity in Your AWS Account - You can use logging features in AWS to determine the actions users have taken in your account, including deletion of users either accidentally or on purpose. Two very useful tools you should be using in this regard include:
AWS CloudTrail - CloudTrail provides event history of your AWS account activity, including actions taken through the AWS Management Console, including user deletions.
AWS Config – Provides detailed historical information about the configuration of your AWS resources, including your IAM users, groups, roles, and policies.
As you can see, utilising the built-in tools that AWS provides can assist you in preventing administrators from deleting users unnecessarily.
As a workaround, you can add a TAG to your user with its key named "DESCRIPTION" and put in the description as a value. Note that for the value, you are very limited to the characters you can use. For instance, you cannot use the apostrophe ('). But it is better than nothing.
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 would like to set up different AWS Identity and Access Management (IAM) users so that if an AWS resource is created by that IAM user, the resource is automatically assigned a specific tag.
For example: if IAM user F creates a new EC2 instance, the instance is automatically tagged as User:MrF. Is it possible to build a custom policy that does this?
My company GorillaStack have an open source lambda function that does exactly that.
The function 'listens' for CloudTrail logs to be delivered and tag the created resource with the ARN of the user that created it. It also support cross account tagging, for cases where a central account collects CloudTrail logs for other accounts.
Github: https://github.com/GorillaStack/auto-tag
Blog Post: http://blog.gorillastack.com/gorillastack-presents-auto-tag
It got a shout out at the 2015 re:Invent conference which is pretty cool :)
Hope that helps!
This is not available when using the AWS APIs directly (i.e. there's no way to command all AWS API's to tag new resources automatically on your behalf), however, depending on the specifics of your use case you could work around that limitation by correlating the creating user with the resource via post hoc tagging:
Workaround
You could activate AWS CloudTrail, which records AWS API calls for your account and delivers log files to you and provides exactly the information you are after:
The recorded information includes the identity of the API caller, the
time of the API call, the source IP address of the API caller, the
request parameters, and the response elements returned by the AWS
service.
Based on that information, a dedicated service of yours could analyze the logs and apply post hoc tags to all resources based on the logged user and created resource via the resp. API actions. Please see my answer to Which user launched EC2 instance? for some caveats/constraints to consider when going down this route.
An even better solution (faster plus I believe cheaper than parsing through CloudTrail logs) is to use CloudTrail but in combination with CloudWatch Events.
This is the basic concept described in a diagram
The implementation is detailed in this article:
https://blogs.aws.amazon.com/security/post/Tx150Z810KS4ZEC/How-to-Automatically-Tag-Amazon-EC2-Resources-in-Response-to-API-Events
The article also describes how to setup an IAM policy that only allows the creator of a resource to perform certain actions (like start / stop, describe, edit, terminate) against it.
I would chose AWS Config. Create a rule that automatically tags resources on creation. No cost, works across multiple accounts. Great for enforcing compliance. https://aws.amazon.com/about-aws/whats-new/2019/03/aws-config-now-supports-tagging-of-aws-config-resources/
Currently there is no such feature on IAM. If what you need is allow/deny based on user names, what you could do is use variables on your policy to allow or deny access based on naming conventions, e.g.:
...
"Resource":"arn:aws:dynamodb:us-east-!:123456789:table/ItemsCatalog_${aws:username}"
...