Deleted main identity-based policy. How it can be recovered? - amazon-web-services

By mistake the main IAM policy of an account was deleted, and now every single service|configuration on AWS console shows "You don't have permission to XXX...." Is there any way to rebuild-recover this policy? Searched all through docs without clear insights.
For example on the IAM dashboard:
User: arn:aws:iam::XXXXXXXX:user/XXXXXXX
Service: iam
Action: GetAccountSummary
On resource(s): *
Context: no identity-based policy allows the iam:GetAccountSummary action
Ty everyone

If you have any other IAM users (or roles) that have permission to create IAM policies and attach them, then log in using one of those. If not, you will need to log in using root credentials (you generally should not login as root, but this is one of those rare cases where you will need to).
Then what you need to do is for user user/XXXXXXX, you will associate a policy with that user that allows it access to everything you need in the console.
From the example you gave, you need a console user that has access to IAM (and specifically iam:GetAccountSummary). Therefore you should look in the IAM policies and see if you have one called AdministratorAccess
If you have it (if that link worked) then skip to step 3. If not, you will need to create this policy. Create a new policy named AdministratorAccess and then use this JSON as the Permissions for the policy
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "*",
"Resource": "*"
}
]
}
Now associate the policy with your IAM User. Go to IAM Users and click on user/XXXXXXX.
The click Add permissions
Attach existing policies directly
check the box next to AdministratorAccess
Next: Review
Add permissions
Log out. Then log back in as user/XXXXXXX
NOTE: In general, you do not want to use a user with AdministratorAccess for most tasks. Consider creating another user with more limited access for everyday use

Was policy deleted for an IAM user or Root user? Getting confused with -
By mistake the main IAM policy of an account was deleted
Deleted in sense removed the policy for user? Or just deleted the policy?
If the policy for an IAM user is removed, you can request another IAM user with admin access or a root user to assign the earlier policy back
If policy is deleted, you may need to create it once again & assign it to user

Related

Grant S3 bucket access to all principals in organization

Scenario:
I have 3 AWS root accounts in the same organization.
admin#mydomain.com
user1#mydomain.com
user2#mydomain.com
user1 created an S3 bucket B1. I want user2 and admin to be able to see and browse B1 on their own S3 dashboard. Is this possible? What policy(policies) that I need to create? Where do I create these policies and how to create them?
**The original question has been edited. Some answers below might not be relevant any more
I believe all you need to do is add Principal: "*" to the policy. This opens access to anyone, but the condition will limit it to the org.
As far as I know, I cannot do the S3 bucket console sharing between root users. I've finally managed to share the bucket created by user1 with an IAM user.
Steps for Root User
Login into AWS console and go to IAM
Create group
Create IAM policy i.e. allowing S3 full access (see below)
Attach policy to group
Create IAM user
For Access type choose AWS Management Console access
Add user to the group you created in step 1
Follow through until you click on create user button
IAM Policy
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "s3:*",
"Resource": "*",
"Condition": {
"StringEquals": {
"aws:PrincipalOrgID": "o-xxxvvvwww8"
}
}
}
]
}
EDIT:
After rigorous trial & error testing, it seems that we don't even need bucket policy for this to work. I've removed the bucket policy and it all still works!
Steps for IAM User
Log into AWS console as IAM user
Go to S3 console. You should be able to see and browse all buckets and objects created by all organization members
Note
Your IAM user would not be able to see the bucket listed on its S3 console dashboard. That shared bucket can only be accessed through direct link. So your root user must provide the URL i.e. https://s3.console.aws.amazon.com/s3/buckets/bucket1/ to your IAM user

AWS IAM Role permission issue

We have just built a new Things Enterprise server hosted at AWS on an EC2 instance and created an application to use AWS IOT. We are getting the following error
“message”: “User: arn:aws:sts::446971925991:assumed-role/Things-Enterprise-Stack-Srv-StackIAMRole-DBHBSMSY05AQ/i-095895d605fab3fa4 is not authorized to perform: sts:AssumeRole on resource: arn:aws:iam::446971925991:role/Bosh-Parking-IOT-Stack-TheThingsStackRoleCD9FBAD2-C44RRJJ53M93”
I have been told
What is the execution role of the TTES instance that is trying to assume the role? The role TTES needs to be able to assume that role. That will give the right permissions.
But I'm not sure what that means, i'm presuming i need to add / alter some permissions within an IAM role. Can someone point me in the right direction Pls.
From the error message it seems that your IAM role for Amazon EC2 has no permissions to assume a role Bosh-Parking-IOT-Stack-TheThingsStackRoleCD9FBAD2-C44RRJJ53M93.
To add such permissions manually you can do the following:
Go to IAM Console->Roles.
In the Roles window, you can use Search bar to locate Things-Enterprise-Stack-Srv-StackIAMRole-DBHBSMSY05AQ role.
Once you find the role, you click on Add inline policy.
Once Create policy window shows, you can go to JSON tab and add the following JSON policy:
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AllowAssumeRole",
"Effect": "Allow",
"Action": "sts:AssumeRole",
"Resource": "arn:aws:iam::446971925991:role/Bosh-Parking-IOT-Stack-TheThingsStackRoleCD9FBAD2-C44RRJJ53M93"
}
]
}
Then click Review Policy, name the policy (e.g. PolicyToAssumeRole) and Create policy
However, based on your policy names (e.g. Stack-Srv-StackIAMRole) it is possible that they have been create by CloudFormation. If this is the case, then manually changing the roles as described above is a bad practice and will lead to drift. Any changes to resources created by CloudFormation should be done using CloudFormation. Sadly, your question does not provide any details about CloudFormation templates used, therefore its difficult to comment on that more.

Understanding IAM Passrole

I couldn't understand the use of IAM Passrole. Can anyone explain with simple example?
I am referring the page : https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_passrole.html but couldn't make much sense out it.
PassRole is a permission granted to IAM Users and resources that permits them to use an IAM Role.
For example, imagine that there is an IAM Role called Administrators. This role has powerful permissions that should not be given to most users.
Next, imagine an IAM User who has permissions to launch an Amazon EC2 instance. While launching the instance, the user can specify an IAM Role to associate with the instance. If the user — who is not an Administrator — were to launch an EC2 instance with the Administrators role, then they could login to the instance and issue commands using permissions from that role. It would be a way for them to circumvent permissions: while not being an administrator themselves, they could assign the IAM Role to a resource, and then use that resource to gain privileged access.
To prevent this scenario, IAM requires that the user be granted the iam:PassRole permission for the Administrators role. If the user does not have that permission, then they will not be permitted to launch the EC2 instance as described, or to assign that role to any other services. It gives them permission to pass a role to a service or resource.
Simply,
when the service B needs the ROLE
A has the iam:PassRole permission about the ROLE,
A can give the ROLE to B.
This is the permission granted for a user to be allowed to pass a role to a service during configuration, without this a user can not perform that binding. You can use this permission combined with resource Arns to limit what roles the user can pass to the service
If for example you have many applications with many different available IAM roles to choose from you might want to restrict the roles a user is able to pass to the service. You would be able to limit this scope using the below statements.
{
"Version": "2012-10-17",
"Statement": [{
"Effect": "Allow",
"Action": [
"iam:GetRole",
"iam:PassRole"
],
"Resource": [
"arn:aws:iam::<account-id>:role/EC2-WordpressRole",
"arn:aws:iam::<account-id>:role/EC2-DatabaseRole"
]
}]
}
In the above scenario there might also be a arn:aws:iam::<account-id>:role/EC2-AdminRole but because this role grants an EC2 host permissions this user should not be able to give to an EC2 it is withheld from the EC2 list by the person who configured the permissions.

Why won't IAM "AmazonEC2FullAccess" policy allow user to launch instances?

The policies attached to the IAM developers group I've set up are as follows:
However, launching new instances won't work. Just after a user in this group selects the key pair to associate with it, i.e. reaches the final step, they get the following message on the next page:
Launch Failed
You are not authorized to perform this operation. Encoded authorization failure message: WZzytnkJ4T3-nkMYslM...
What's preventing developers to launch new instances, given these policies?
It could be that the instance is being launched with an IAM Role, and the group does not have iam:PassRole permissions (which are outside of the ec2:* permissions space).
You should add a policy like this:
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "PassRoleToEC2",
"Effect": "Allow",
"Action": "iam:PassRole",
"Resource": "*"
}
]
}
This saying "Allow this user to pass any (*) role to an EC2 instance".
Actually, you should limit such permissions only to specific roles, otherwise a normal user could select an Admin role. Then, if they logged into the instance, they would have access to credentials that have Admin permissions on the whole AWS Account.
Alternatively, do not select a Role when launching the instance. It should then launch okay (assuming that this is the issue causing the error).
The user needs a PassRole permission.
A Role must be associated with the "Launch" of the EC2 instance.
The PassRole permission helps you make sure that a user doesn’t pass a role to an EC2 instance where the role has more permissions than you want the user to have.
As in the following example, if the EC2 Launch requires access to S3 you User must be able to pass the S3 role required.
{
"Effect":"Allow",
"Action":"iam:PassRole",
"Resource":"arn:aws:iam::123456789012:role/S3Access"
}
Link to documentation:
https://aws.amazon.com/blogs/security/granting-permission-to-launch-ec2-instances-with-iam-roles-passrole-permission/

How to assign IAM role to users or groups

I know how to create user, group and role in AWS IAM.
I can also attach policies to each of them.
For example, after selecting a group, you can go to permissions tab, and attach some policies to it.
However, I don't know how to attach a role to a user or group.
I looked on documentation and forums, but did not find anything, and appreciate your help.
You can't assign IAM role to IAM user or group, see the notes from this AWS official doc :- https://aws.amazon.com/iam/faqs/
Q: What are IAM roles and how do they work?
AWS Identity and Access Management (IAM) roles provide a way to access AWS by relying on temporary security credentials. Each role has a set of permissions for making AWS service requests, and a role is not associated with a specific user or group. Instead, trusted entities such as identity providers or AWS services assume roles. For more information, see IAM roles.
It looks like it's not straight forward to attach IAM role to IAM user, follow https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html on how to do it.
In the past, I've created IAM role for my ec2-instance and when launching that instance, I can choose that IAM role and my ec2-instance will have all the permissions set in that IAM role, likewise you can assign a role to other ec2-services, this is the most used scenario of IAM role.
To assign IAM role to an IAM user, do the following:
Open the IAM Dashboard
Select the role that you want to assign to an IAM user
Edit the trust policy
add the ARN of the IAM user in the Principal's section
That's it. Now test it out using the Switch Role feature.
Follow the same procedure to assign IAM role to an IAM group.
I'd be careful about modifying trust relationships - if they're poorly configured they can lead to your account or resource being compromised.
When granting explicit access to a user/group on the same account you should not be modifying the Trust Relationship of the role. To clarify further:
The roles should have a trust relationship of something like this:
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::<YOUR ACC ID>:root"
},
"Action": "sts:AssumeRole",
}
]
}
What this essentially means is I'm delegating permissions to this role to the account listed in "arn:aws:iam::<YOUR ACC ID>:root" -- its now up to the IAM operator of that account to grant access to this role using a policy such as this one:
{
"Version": "2012-10-17",
"Statement": [
{
"Action": [
"sts:AssumeRole"
],
"Effect": "Allow",
"Resource": "<role arn>"
}
]
}
This policy can be attached to a user or group and that user or the users in the group will be able to assume the role that has the trust relationship above.
A User can be placed in a group to gain the permissions associated with the group or can assume a role to enter a session where permissions are now that of the roles. Users have an access key and secret access key.
Groups are only used to provide permissions to users, i.e a user is placed in a group.
Roles are a temporary set of permission, i.e a user assumes a role and is granted temporary credentials for the life of the session. Role sessions will have an access key, secret access key, and a session token.
An IAM role is an IAM entity that defines a set of permissions for
making AWS service requests. IAM roles are not associated with a
specific user or group. Instead, trusted entities assume roles, such
as IAM users, applications, or AWS services such as EC2.
It is clearly documented here.
https://aws.amazon.com/iam/faqs/