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.
Related
We have started initially by defining roles with admin access policy attached. But now we want them to have policy with only specific permissions that are minimum and does not create any issues for using these roles.
Looking at "Access Advisor" tab on each role under AWS IAM console, it gives good amount of information that exactly which AWS services getting used and permission level information only for EC2, IAM, Lambda, and S3 management actions services. But for rest of other AWS services, missing that what specific permission for that particular service is required.
Also not having AWS Organizations master account access as mentioned in this tutorial: Viewing last accessed information for Organizations.
So is there a way I can get the permissions level info for services other than EC2, IAM, Lambda, and S3 management actions?
Thanks.
So is there a way I can get the permissions level info for services other than EC2, IAM, Lambda, and S3 management actions?
Sadly, there is no such way provided by AWS. So basically its try-and-see approach to get what you want. You can try some third party tools, which may be helpful, such as zero-iam, but ultimately, you will need custom solution to match your requirements.
There is also IAM Access Analyzer which is different then Access Advisor. But its also limited to some services only.
I'm trying to create an AWS Control Tower landing zone for my AWS organization, and am getting a message saying You must unsubscribe your organization from AWS CloudTrail so that AWS Control Tower can proceed. During the setup process, AWS Control Tower creates a new trail in the audit account that's part of your landing zone. How do I do this? Does this mean stopping all CloudTrail trails from sending logs, or is there an organization-wide setting to disable?
AWS Control Tower needs trusted access to be disabled for both Cloudtrail and Config. To disable this you need to login into the Organization management account, and go to AWS Organizations > Services > Disable Config/Cloudtrail.
Trusted access enabled at an Organization level enables these services to inject service roles in all member accounts where they need to change something. Disabling this for Cloudtrail would result in the Organization trail not working anymore, however the master trail would still be intact. All shadow trails in member accounts would be disabled. AWS still allows you to search/filter/download cloudtrail management events in each of the member accounts for last 90 days, just that they wouldn't be transferred to a central s3 bucket for storage.
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.
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.
We have large number of IAM users ( in hundreds, can increase more then 1000 in future ).
All the IAM users have access to create EC2 instances. Simultaneously around 30-40 users will be working and creating EC2 instances.
In AWS Management Console, an IAM user can see all the instances created by other IAM users as well.Is it possible to visibly make him see only those EC2 instances which he created and hide all the other instances created by other IAM users?
I do agree that IAM users can give names and tags to recognise their instances. However i am looking for visibly hiding those resources which he has not created.
If IAM policies allowed specifying a required filter, this would be possible. But you can't specify it, so it's not possible.
What you want is called Organizations - You can give each group their own AWS account, so they can see their own billing, etc.
Reserved Instances can flow from the master account to sub account
Bills flow from the sub accounts to the master account
All your users can remain in the master account, you just give them AssumeRole capabilities to view their account.
You can apply Service Control Policies that prevent sub-accounts from doing things.
You may think management is "easier" with one account - but the opposite is true. Just like you should treat servers as "Cattle not Pets" (i.e. they are disposable), you should think of AWS accounts as disposable. Some organizations give each developer their own AWS account, and only a build server can modify the Staging/Prod accounts via TerraForm or CloudFormation.
What you would typically use for this is resource level permissions. What resources / what you can control varies from API call to API call in AWS. In particular, what you would want is a resource-level permission on the DescribeInstances API call. Unfortunately, AWS does not currently support resource-level permissions on this API Call.