Does AWS lock the AWS account when a ransomware attack similar kind of the event happens? I'm trying to understand this situation for my Backup and Restore strategy for the new AWS account
Related
I'm using AWS SSO login with AWS CLI to assume role with IAM privileges. This is needed when running Terraforms that needs to create roles, etc. into IAM.
The problem is that AWS SSO CLI login already uses assumed role and assuming other role (chaining role) seems to have 1 hour limitation and there doesn't seem to be any way around this.
This is really annoying, if the role expires during Terraform operation as the state gets locked. This happens way too often.
So has anyone found a way to overcome the 1 hour limit when using AWS SSO, AWS CLI and terraform?
I guess one way would be to give all users SSO-Admin privileges but this seems bit unsafe.
On expiry of IAM roles:
What is the logic for IAM roles to expire, when you need them for longer. I really cannot see it.
How do you when processing, get the an extension of the IAM role without some serious failure?
I did the IAM course but felt that was not well addressed.
E.g. a long running AWS EMR Spark data pipeline on a massive scale for cross account access?
If the Spark data pipeline has finished the Stage of reading from S3 and that role expires, may be that does not matter if you do not save subsequently to S3.
Instance roles such as those used in EMR are renewed automatically:
The application is granted the permissions for the actions and resources that you've defined for the role through the security credentials associated with the role. These security credentials are temporary and we rotate them automatically. We make new credentials available at least five minutes before the expiration of the old credentials.
Look in the AWS SDK for com.amazonaws.auth.InstanceProfileCredentialsProvider; this is called by the clients to get the IAM Credentials. It spawns a thread com.amazonaws.auth.EC2CredentialsFetcher which does HTTP requests to the special 169.x.x.x http server which provides these details. Every spark worker creating an s3 client (or s3a, on ASF builds) will instantiate an InstanceProfileCredentialsProvider, after which everything will "just work"
IAM roles used to always expire after 1h; any job lasting 65+ minutes would have triggered a refresh.
try it and see.
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.
I'm looking for something that can programmatically spin up instances for other AWS users after oauth. Is there something like this that Amazon provides? So they can just login with AWS account and then I can make AWS calls on their behalf.
Is there anything like this out there?
There's no logging in here. You need a cross-account role, supplied by the owner of the other account.
There is nothing like this.
It would have massive security implications.
Note that the primary entity in AWS is not the user, it is the "account." Accounts have users, and those users can only do what the account has authorized them to do.
For one AWS account ("mine") to allow another AWS account ("yours") to perform actions on behalf of my account (technically, not on behalf of "me"), I have to explicitly give you permission to do so, via IAM. One solution is to create a role with the necessary permissions and delegate access to you.
But this is unlikely to be something a well-informed user would permit, since you could easily run up substantial expenses for the user. Allowing such external access would not be a good practice.
There is, however, a way for users to launch your software on EC2 and optionally pay you a license fee billed on your behalf by AWS, through the AWS Marketplace, which is oriented towards a one-click experience for the user.
I don't know what is happening with my AWS account. I was using Github $150 student pack on my AWS account.
I hardly created any EC2 instances on my AWS account. But now I'm fed up of terminating large sized EC2 instances which are automatically created in my account.
And all of above, I'm charged $2871.
Any solution, please? What measure can I take to stop being charged? I had contacted AWS support but they said to wait for 24 hours.
P.S. - I use my parents credit card.
It is likely that somebody has obtained your credentials and are using your account without permission (eg for Bitcoin mining).
I recommend that you contact AWS Customer Service immediately (NOT Customer Support) and tell them that you suspect fraudulent access on your account. Select "Billing and Account" enquiries.
Some other things to check:
Confirm that you have no Auto Scaling groups (in the Amazon EC2 console)
Confirm that no other Users or Roles exist in the IAM console
Delete your Access Keys associated with your existing Users
Delete your Customer Master Access Key in your Security Credentials page
Have a look at CloudTrail. It's on by default and it will track API calls. You most likely either have a badly configured autoscaling group, or your keys have been leaked. CloudTrail should tell you who is doing what.