What is difference between S3:DeleteBucket and S3:DeleteObject IAM actions?
My understanding is that S3:DeleteBucket is needed to provide permission to delete a bucket.
But, how does it differ from S3:DeleteObject?
I have read DeleteObject but it is not making any understanding to me.
Related
The situation is:
A lambda function is created using a SAM/CloudFormation. A policy is attached to allow this function to access an existing bucket (in the same region). This looks somehow like this:
MyFunction:
Type: AWS::Serverless::Function
Properties:
.....
Policies:
- Statement:
- Effect: Allow
Action:
- "s3:ListBucket"
- "s3:PutObject"
- "s3:GetObject"
Resource:
- "arn:aws:s3:::my-great-existing-bucket"
- "arn:aws:s3:::my-great-existing-bucket/*"
This means: Without modifying the policy of the existing bucket, the newly created lambda-function will now have access to that bucket.
But in this case this already existing bucket is additionally encrypted with an existing customer managed KMS key (again in the same region) so access will still be denied to the Lambda function. The goal would be to add the policy to use that existing key also directly to cloud-formation template.
I found this link:
https://docs.aws.amazon.com/kms/latest/developerguide/iam-policies.html
My interpretation would be, that the named goal would usually be achieved only the other way round:
You need to modify the policy of the KMS-key. But they Key is of course not managed via the Cloud Formation Stack and therefore not manageable here (or am I wrong about that?).
So the only way to achieve it would be to activate general IAM Policies for the KMS-key?
https://docs.aws.amazon.com/kms/latest/developerguide/key-policies.html#key-policy-default-allow-root-enable-iam
Is that understanding correct?
So the only way to achieve it would be to activate general IAM Policies for the KMS-key?
Yes. That's correct. If your customer managed KMS key does not have it, you have to modify KMS policy to allow lambda role. If you activate general IAM Policies, then you can just modify the lambda execution role with permissions to the KMS key.
After creating an S3 bucket in AWS - I want to find out how permissions for Read and Write access to the S3 bucket should be provided?
I am thinking that IAM user permissions and S3 bucket permissions are different. What I am mean is - an IAM user with no permissions on AWS can be granted access to the S3 bucket by just adding him to the S3 buckets permissions for read or read+write accordingly. And S3 permissions have got nothing to do with IAM permissions>
Is the above understanding correct? Please correct and elaborate if the above is wrong?
And S3 permissions have got nothing to do with IAM permissions
This is not the case. The effective permission for the bucket and its objects are union of the IAM identity based permissions (i.e. those attached to IAM user,role, group) plus bucket policies plus other permissions (SCPs, IAM boundaries), which I don't mention for simplicity.
By default bucket and objects are private. You can Allow access to them using either IAM policies, bucket policies or both. Effective permissions will be the union of all these individual permissions. This means that you can use bucket policy to grant access to object1 and IAM policy to grant access to object2 to the same IAM user. The said user will be able to access both objects.
This behavior changes when there is Deny, as deny always wins. So an IAM user can have Allow in IAM policies to a given bucket, but the bucket can have Deny for that user. The result will be Deny always.
Subsequently, all these mean that bucket polices and IAM permissions should be considered together and are inter-connected with each other. Thus, you can't say that "S3 permissions have got nothing to do with IAM permissions".
An IAM User has no permissions by default. If they wish to do anything via an authenticated API call, they must be granted permission to do so.
Even if an Amazon S3 bucket policy grants access to an IAM User, they cannot access content in Amazon S3 unless their IAM permissions allow them to make the associated API call (eg ListBuckets or GetObject).
Please note that I am referring to an authenticated API call, not an Anonymous HTTP requests via a web browser URL.
A Bucket Policy can grant "public access" by referring to "Principal": "*" (which means that even unauthenticated users can retrieve content via a URL), or it can grant access to specific IAM Users and IAM Roles. However, if that user/role doesn't have permission to call any S3 Actions, then they cannot access the bucket.
A Deny policy from either IAM or a Bucket Policy takes precedence over Allow. So, an IAM User with permission to access a bucket can be denied by the Bucket Policy, and vice versa.
In AWS IAM is the place to generate all policies and to assign them to users and/or roles.
As a general rule, AWS recommends using S3 bucket policies or IAM policies for access control.
"S3 ACLs are a legacy access control mechanism that predates IAM. However, if you already use S3 ACLs and you find them sufficient,
there is no need to change."
By default, a user/role is assuming the policies provided by an SCP which stands for "service control policy". It is very similar to the policies you probably faced but this is provided by the account level/or organization level.
Among all options to generate and assume policies, there is a logical "and" which mean that in case there is at least 1 "deny" among the policies it will restrict access of a user/role to a specific bucket for instance in your case
Below is the policy rule to create once but cannot delete the policy once created through cloudFormation. These are managed policies.
- Effect: Deny
Action:
- "iam:CreatePolicyVersion"
- "iam:DeletePolicy"
- "iam:DeletePolicyVersion"
- "iam:SetDefaultPolicyVersion"
Resource:
- !Sub "arn:aws:iam::${AWS::AccountId}:policy/some-permission-boundary"
- !Sub "arn:aws:iam::${AWS::AccountId}:policy/some-policy"
- Effect: Deny
Action:
- "iam:DeleteRolePermissionsBoundary"
Resource:
- "*"
But through AWS console, I went and deleted those two policies directly, by selecting the policy, Policy actions ---> delete
Later I deleted the stack that created those two policies.
How to avoid deletion of policies? Why above rule did not avoid deletion of policy? given any Principal
Policies only impact principals to which they are attached.
Creation of a policy that denies (or allows) any action doesn't actually do anything to deny (or allow) that action, unless the policy is subsequently attached to a principal (IAM user, group, or role).
You manage access in AWS by creating policies and attaching them to IAM identities (users, groups of users, or roles) or AWS resources. A policy is an object in AWS that, when associated with an identity or resource, defines their permissions. (emphasis added)
https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html
Since everything is initially denied by default, the fact that you cam delete the policy means your IAM user necessarily has been granted permission to delete the policy (more probably, you have permission to delete any policy) -- you already have a policy attached to your user that allows this. The best way prevent an action is to not grant permission to perform the action. You could also associate this policy with all users or a group of all users, then only the root user for your account could delete it -- but that's usually the wrong solution, because it's cancelling out a misconfiguration that granted the permission initially.
For every project, we create two AWS accounts. One for development and staging and one for production. The developers have an IAM user in the root account and users assumed roles in the other accounts to access those.
I want to create a policy, which allows the developer to do nearly everything in the development account, including creating new policies and attaching those (for new resources, etc.), but the developer should not be able to modify his own role / attach new roles to himself.
Any ideas?
I'm facing the same issue I've already posted a question about that here (similar issue).
After a lot of research, I came to a conclusion: do not allow developers to create roles and policies.
Why?
I didn't find a way to answer my question allowing user creating roles only for resources and not for principals.
Even if I've found a solution for 1., there is a flaw: suppose developers can create roles for resources but not for principals and he (she) can create every policy he (she) wants. In this scenario, he (she) could create a policy for Lambdas and inside Lambdas, a script could be written to execute actions allowed by policies attached.
My final solution:
Create two groups called Developers and IAM in which IAM users can create any roles and policies, thus is trusted developers, and Developers can only attach policies whose path is services-roles, for instance.
Example a role attached to Developers group - allow users create everything except all iam actions except PassRole with path service-roles:
DevelopersIAMManagedPolicy:
Type: AWS::IAM::ManagedPolicy
Properties:
Description: 'Developers.'
# Groups:
# - String
PolicyDocument:
Version: '2012-10-17'
Statement:
- Effect: Allow
Action: iam:PassRole
Resource: 'arn:aws:iam::*:role/projects-roles/*'
- Effect: Allow
NotAction: iam:*
Resource: '*'
I'm open to new ideas, but this solution is the most secure I've reached.
There is a policy attached to user/role which is allowed to create other policies and roles, but, for example, original role doesn't have permissions to do s3:PutObject. Is there any way I can prevent this role/user from creating another policy which allows s3:PutObject and elevating it's own permissions by that?
If you grant users the ability to create policies and roles, then you trust them not to abuse it. Very few admins should have this ability.
The way to solve your case is for an uber-admin to create policies and roles, and for your user to be restricted to which policies/roles he can attach (see related article). You can also implement automation to validate the policies created by your uber-admins meet certain conditions.