We can enable/disable regions at the account level by logging in as the AWS account administrator and going to My Account -> AWS Regions. Only "opt-in" regions can be enabled or disabled e.g."Asia Pacific (Hong Kong)". All other regions are "Enabled by default" on an AWS account and cannot be disabled.
Challenge is, that this operation doesn't have API to manage this setting therefore no terraform either.
We have written script (uses selenium), but it has to be executed manually by operator from Win and authenticate using ADFS.
We are looking to automate entire account provisioning workflow, but missing on #2 -
Using AWS Organizations create new child account (done - API available)
Enable e.g. Hong Kong region programmatically (from linux cmd / lambda) - Missing
https://docs.aws.amazon.com/general/latest/gr/rande-manage.html
Enable Global STS (done - API available)
https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_enable-regions.html
thanks,
D
Now it is possible to programmatically enable a non default region, e.g. Zurich (eu-central-2). See the Manage account regions documentation.
Via boto3 it is possible as well with the enable_region method. Keep in mind that it might take several hours until it's usable.
To check if the enabling succeeded use the get_region_opt_status method
This is not publicly available within the API as of the time of this answer.
From the AWS documentation it states the below
If a Region is disabled by default, you can use the AWS Management Console to enable and disable it.
There are actually permissions for enabling and disabling, but currently the verbs are not exposed programmatically.
As the AWS console is API driven this will be privately accessible, hopefully in the future it will be allowed in the public.
Related
I wanted to know if there was a way to track alerts or audit anything that happens with the AWS account like who changed what and why. I did find this https://docs.aws.amazon.com/opensearch-service/latest/developerguide/audit-logs.html where they use a comand line for enabling audit logs on an existing domain: aws opensearch update-domain-config --domain-name my-domain --log-publishing-options "AUDIT_LOGS={CloudWatchLogsLogGroupArn=arn:aws:logs:us-east-1:123456789012:log-group:my-log-group,Enabled=true}" but this is in regard to Amazon OpenSearch Service which I believe is only free for 12 months if you haven't used already. AWS Audit Manager. I am aware there are services that can do this but require a fee and I wanted to know if there were any free options
From the AWS documentation:
With AWS CloudTrail, you can monitor your AWS deployments in the cloud by getting a history of AWS API calls for your account, including API calls made by using the AWS Management Console, the AWS SDKs, the command line tools, and higher-level AWS services. You can also identify which users and accounts called AWS APIs for services that support CloudTrail, the source IP address from which the calls were made, and when the calls occurred. You can integrate CloudTrail into applications using the API, automate trail creation for your organization, check the status of your trails, and control how administrators turn CloudTrail logging on and off.
AWS Config provides a detailed view of the resources associated with your AWS account, including how they are configured, how they are related to one another, and how the configurations and their relationships have changed over time.
Basically, AWS CloudTrail keeps a log of API calls (requests to AWS to do/change stuff), while AWS Config tracks how individual configurations have changed over time (for a limited range of resources, such as Security Group rule being changed).
Our company has reached a point where too many demo projects have been launched and left rolling on their own without having anyone actually assigned to the projects anymore.
How does one set up something that would detect unused projects/resources and send an email to the owning IAM User?
It might be fair to assume that CloudFormation is being used by almost all the projects (generally through a CodeStar, Elastic Beanstalk, or Lambda set up).
If no reply/activity is manifested by the contacted IAM User, maybe another email could be sent to some administrator notifying about such a situation, too.
I have the same need to monitor all ressources used/unused, non compliance ... in my vpc.
I would go to AWS config to , among all feature, get a view of ressources relationship, and AWS service catalog to "regroup" authorized ressources and follow a bunch of informations.
Furthermore AWS config is deploy as a cloud formation stack.
If you dev deploy through cloud formation, you can dig a new feature called Cloud Formation Hook as compliance feature to inspect stack ressource before provisionning, and list all ressource within DynamoDb.
You can check also this (AWS organizations - List resources by AWS account?)
Have a look also aws-nuke that list ressource - and delete them with the correct quote - for any aws account.
Though the console AWS Account > IAM > Account Settings your able to enable and disable regions
Is there a way to do that through either Boto3 or Terraform ?
That page you are referencing is only for enabling/disabling regional endpoints of the AWS STS service. That doesn't actually disable the use of a region. I can't find any API to manage this setting programatically.
You can enable/disable regions at the account level by logging in as the AWS account administrator and going to My Account -> AWS Regions. However only "opt-in" regions can be enabled or disabled. At this time the only "opt-in" regions are "Middle East (Bahrain)" and "Asia Pacific (Hong Kong)". All other regions are "Enabled by default" on an AWS account and cannot be disabled. Again, I am not aware of an API to manage this setting.
If you want to restrict IAM users from accessing or creating resources in specific regions the correct method of doing this is through IAM policies, per this AWS Blog Post. This of course can be managed through the IAM API.
I'm trying to set up a Site to Site connection between our on-premise server and our cloud infrastructure. In our premises we have a SonicWall firewall installed and, since SonicOS 6.5.1.0 it's now easy to put an AWS access key and AWS Secret Key and let the software configure everything via SDK.
The problem is that the tutorial on how to configure the firewall (p. 8) says:
The security policy used, either for a group to which the user belongs or attached to the user directly, must
include the following permissions:
• AmazonEC2FullAccess – For AWS Objects and AWS VPN
• CloudWatchLogsFullAccess – For AWS Logs
Since it's not ideal to give anyone the full access to Amazon EC2 do you know which features SonicWall actually needs so I can disable everything else and follow the principle of least privilege?
Without looking into the code for SonicWall itself, it is not going to be easy to know exactly which API calls it's going to make to EC2. If you are prepared to at least temporarily grant full EC2 access, you could use AWS CloudTrail to monitor exactly which API calls are being made by the IAM user associated with your on-premises server, and then update your specific policy to match those calls.
Alternatively, start with the full access IAM policy template and go through and deny any calls you think are completely unrelated to SonicWall's functionality.
If you trust SonicWall then probably the easiest thing to do is to just allow the full EC2 access it claims is required (or start there and gradually remove them until something breaks!)
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}"
...