I'm trying to create a policy, whose JSON is:
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "VisualEditor0",
"Effect": "Allow",
"Action": [
"iam:ListPolicies",
"kms:UntagResource",
"kms:ListKeyPolicies",
"kms:ListRetirableGrants",
"kms:GetKeyPolicy",
"iam:ListRoles",
"kms:ListResourceTags",
"iam:ListInstanceProfiles",
"kms:ListGrants",
"kms:GetParametersForImport",
"kms:DescribeCustomKeyStores",
"kms:ListKeys",
"kms:TagResource",
"s3:ListAllMyBuckets",
"kms:GetKeyRotationStatus",
"kms:ListAliases",
"kms:DescribeKey",
"s3:HeadBucket"
],
"Resource": "*"
},
{
"Sid": "VisualEditor1",
"Effect": "Allow",
"Action": "s3:ListBucket",
"Resource": "arn:aws:s3:::644748426467:"
}
]
}
But when I click on Review Policy, I get The policy failed legacy parsing (see screenshot below).
Any idea what my wrong syntax is?
Edit 1:
The following gives the same The policy failed legacy parsing error:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:ListAllMyBuckets"
],
"Resource": [
"arn:aws:s3:::*"
]
},
{
"Sid": "VisualEditor0",
"Effect": "Allow",
"Action": [
"iam:ListPolicies",
"kms:ListKeyPolicies",
"kms:UntagResource",
"kms:ListRetirableGrants",
"kms:GetKeyPolicy",
"iam:ListRoles",
"kms:ListResourceTags",
"iam:ListInstanceProfiles",
"kms:ListGrants",
"kms:GetParametersForImport",
"kms:DescribeCustomKeyStores",
"kms:ListKeys",
"kms:TagResource",
"kms:GetKeyRotationStatus",
"kms:ListAliases",
"kms:DescribeKey"
],
"Resource": "*"
},
{
"Sid": "VisualEditor1",
"Effect": "Allow",
"Action": "s3:ListBucket",
"Resource": [
"arn:aws:s3:::*"
]
}
]
}
I figured out the correct format for the policy.
When entering resources from the IAM/edit-policy GUI, the resulting JSON is updated with a wrong format.
The correct format for S3 permissions should be arn:aws:s3:::xxxxxx and not arn:aws:::xxxxxx:.
Note that when one enters, manually, the correctly formatted S3 resource in the JSON, the GUI would display a warning.
This is my working JSON:
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "VisualEditor0",
"Effect": "Allow",
"Action": [
"kms:GetParametersForImport",
"kms:TagResource",
"kms:UntagResource",
"kms:ListKeyPolicies",
"kms:ListRetirableGrants",
"kms:GetKeyRotationStatus",
"kms:GetKeyPolicy",
"cloudtrail:CreateTrail",
"kms:DescribeKey",
"s3:ListBucket",
"kms:ListResourceTags",
"kms:ListGrants"
],
"Resource": [
"arn:aws:s3:::644748xxxxxx",
"arn:aws:kms:*:644748xxxxxx:key/*",
"arn:aws:kms:*:644748xxxxxx:alias/*",
"arn:aws:cloudtrail:::*"
]
},
{
"Sid": "VisualEditor1",
"Effect": "Allow",
"Action": [
"iam:ListPolicies",
"kms:DescribeCustomKeyStores",
"kms:ListKeys",
"iam:GetPolicyVersion",
"iam:GetRole",
"iam:CreateServiceLinkedRole",
"kms:ListAliases",
"iam:ListRoles",
"iam:ListRolePolicies",
"iam:ListInstanceProfiles"
],
"Resource": "*"
}
]
}
Related
I am trying to figure out an AWS Policy that will make it so MFA is enforced for Console users but not for CLI users, anyone have any ideas for this?
No matter what I do I can't seem to exclude CLI users.
This is what I have been using.
I have tried changing lines 102-104 as a reverse version but when I do that I lose all access to AWS except through CLI..
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AllowViewAccountInfo",
"Effect": "Allow",
"Action": [
"iam:GetAccountPasswordPolicy",
"iam:ListVirtualMFADevices"
],
"Resource": "*"
},
{
"Sid": "AllowManageOwnPasswords",
"Effect": "Allow",
"Action": [
"iam:ChangePassword",
"iam:GetUser"
],
"Resource": "arn:aws:iam::*:user/${aws:username}"
},
{
"Sid": "AllowManageOwnAccessKeys",
"Effect": "Allow",
"Action": [
"iam:CreateAccessKey",
"iam:DeleteAccessKey",
"iam:ListAccessKeys",
"iam:UpdateAccessKey"
],
"Resource": "arn:aws:iam::*:user/${aws:username}"
},
{
"Sid": "AllowManageOwnSigningCertificates",
"Effect": "Allow",
"Action": [
"iam:DeleteSigningCertificate",
"iam:ListSigningCertificates",
"iam:UpdateSigningCertificate",
"iam:UploadSigningCertificate"
],
"Resource": "arn:aws:iam::*:user/${aws:username}"
},
{
"Sid": "AllowManageOwnSSHPublicKeys",
"Effect": "Allow",
"Action": [
"iam:DeleteSSHPublicKey",
"iam:GetSSHPublicKey",
"iam:ListSSHPublicKeys",
"iam:UpdateSSHPublicKey",
"iam:UploadSSHPublicKey"
],
"Resource": "arn:aws:iam::*:user/${aws:username}"
},
{
"Sid": "AllowManageOwnGitCredentials",
"Effect": "Allow",
"Action": [
"iam:CreateServiceSpecificCredential",
"iam:DeleteServiceSpecificCredential",
"iam:ListServiceSpecificCredentials",
"iam:ResetServiceSpecificCredential",
"iam:UpdateServiceSpecificCredential"
],
"Resource": "arn:aws:iam::*:user/${aws:username}"
},
{
"Sid": "AllowManageOwnVirtualMFADevice",
"Effect": "Allow",
"Action": [
"iam:CreateVirtualMFADevice",
"iam:DeleteVirtualMFADevice"
],
"Resource": "arn:aws:iam::*:mfa/${aws:username}"
},
{
"Sid": "AllowManageOwnUserMFA",
"Effect": "Allow",
"Action": [
"iam:DeactivateMFADevice",
"iam:EnableMFADevice",
"iam:ListMFADevices",
"iam:ResyncMFADevice"
],
"Resource": "arn:aws:iam::*:user/${aws:username}"
},
{
"Sid": "DenyAllExceptListedIfNoMFA",
"Effect": "Deny",
"NotAction": [
"iam:CreateVirtualMFADevice",
"iam:EnableMFADevice",
"iam:GetUser",
"iam:ListMFADevices",
"iam:ListVirtualMFADevices",
"iam:ResyncMFADevice",
"sts:GetSessionToken"
],
"Resource": "*",
"Condition": {
"BoolIfExists": {
"aws:MultiFactorAuthPresent": "false"
}
}
}
]
}
The AWS Management Console makes API calls on behalf of users. Therefore, the same policy would apply to API calls as console calls.
Therefore, if you want a different set of rules to apply within the AWS Management Console, you would need to create a separate IAM User that has:
A password for login to the console
Does not have an Access Key & Secret Key (so they can't use the CLI)
Requires Multi-Factor Authentication
I am trying to set up a simple AWS SFTP server with a scoped-down policy but keep getting permission denied errors when trying to put and get.
Here is IAM Role with generic S3 bucket access:
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AllowListingOfUserFolder",
"Action": [
"s3:ListBucket",
"s3:GetBucketLocation"
],
"Effect": "Allow",
"Resource": [
"arn:aws:s3:::SOME-EXAMPLE-BUKCET"
]
},
{
"Sid": "HomeDirObjectAccess",
"Effect": "Allow",
"Action": [
"s3:PutObject",
"s3:GetObject",
"s3:DeleteObjectVersion",
"s3:DeleteObject",
"s3:GetObjectVersion"
],
"Resource": "arn:aws:s3:::SOME-EXAMPLE-BUCKET/*"
}
]
}
And this is the scoped-down policy which I attach to the user when I create it in the SFTP panel:
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "VisualEditor0",
"Effect": "Allow",
"Action": "s3:ListBucket",
"Resource": "arn:aws:s3:::${transfer:HomeBucket}",
"Condition": {
"StringLike": {
"s3:prefix": [
"${transfer:UserName}/*",
"${transfer:UserName}"
]
}
}
},
{
"Sid": "VisualEditor1",
"Effect": "Allow",
"Action": "s3:GetBucketLocation",
"Resource": "arn:aws:s3:::SOME-EXAMPLE-BUCKET"
},
{
"Sid": "VisualEditor2",
"Effect": "Allow",
"Action": "s3:ListAllMyBuckets",
"Resource": "*"
},
{
"Sid": "VisualEditor3",
"Effect": "Allow",
"Action": [
"s3:PutObject",
"s3:GetObjectAcl",
"s3:GetObject",
"s3:DeleteObject"
],
"Resource": [
"arn:aws:s3:::${transfer:HomeDirectory}/*",
"arn:aws:s3:::${transfer:HomeDirectory}*"
]
}
]
}
The goal is for a user to log in and land in their home directory with read/write/delete permissions for just that directory. I've tried various policies from the following links but never quite get what I need:
Connecting to AWS Transfer for SFTP
https://docs.aws.amazon.com/transfer/latest/userguide/users.html
https://docs.aws.amazon.com/transfer/latest/userguide/requirements-roles.html
I always either get no access at all and everything is denied (i.e. can't even ls). Or I can ls but can't do anything else like mkdir, put, get, etc...
In the scoped-down policy, why do you use transfer:UserName in the ListBucket condition rather than transfer:HomeDirectory like in the Put/Get/DeleteObject statement? Is the HomeDirectory of the user the same as its username?
What happens when you try something like this?
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "VisualEditor0",
"Effect": "Allow",
"Action": "s3:ListBucket",
"Resource": "arn:aws:s3:::${transfer:HomeBucket}",
"Condition": {
"StringLike": {
"s3:prefix": [
"${transfer:HomeDirectory}/*",
"${transfer:HomeDirectory}"
]
}
}
},
{
"Sid": "VisualEditor1",
"Effect": "Allow",
"Action": "s3:GetBucketLocation",
"Resource": "arn:aws:s3:::SOME-EXAMPLE-BUCKET"
},
{
"Sid": "VisualEditor2",
"Effect": "Allow",
"Action": "s3:ListAllMyBuckets",
"Resource": "*"
},
{
"Sid": "VisualEditor3",
"Effect": "Allow",
"Action": [
"s3:PutObject",
"s3:GetObjectAcl",
"s3:GetObject",
"s3:DeleteObject"
],
"Resource": [
"arn:aws:s3:::${transfer:HomeDirectory}/*",
"arn:aws:s3:::${transfer:HomeDirectory}*"
]
}
]
}
Do not use ${transfer:Username} in the scoped down policy. Also, make sure you specify it as Policy key within secrets manager.
I have documented the full setup here in case you need to reference it - https://coderise.io/sftp-on-aws-with-username-and-password/
Can you confirm me that with the following policy:
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "VisualEditor0",
"Effect": "Allow",
"Action": [
"s3:CreateBucket",
"s3:ListBucket"
],
"Resource": "arn:aws:s3:::viessmann"
},
{
"Sid": "VisualEditor1",
"Effect": "Allow",
"Action": [
"s3:PutObject",
"s3:GetObject",
"s3:DeleteObject"
],
"Resource": "arn:aws:s3:::viessmann/medias/*"
}
]
}
It would allow me to write the following object in the given path:
https://viessmann.s3-eu-west-1.amazonaws.com/medias/cache/brochure_thumbnail_medium/5abcf6b35e02b.jpg
Right now, I'm getting an 403 Forbidden response.
I have a test account where I'd like to give developers access to try out anything they'd like EXCEPT I don't want to give them permissions to add / delete / mess with other users. I tried allowing everything and then denying IAM access but then they couldn't change their own password. For example:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"*"
],
"Resource": [
"*"
]
},
{
"Effect": "Deny",
"Action": [
"iam:*"
],
"Resource": [
"*"
]
},
]
}
This made it so users got the following error when they tried to login and change their pw:
User is not authorized to perform iam:ChangePassword
For a more concise answer you can use wild cards. Not perfectly future proof but those are most of the damaging verbs. :)
Also I found the policy simulator very useful: IAM policy simulator
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "*",
"Resource": "*"
},
{
"Effect": "Deny",
"Action": [
"iam:Add*",
"iam:Create*",
"iam:Deactivate*",
"iam:Delete*",
"iam:Detach*",
"iam:Enable*",
"iam:PassRole",
"iam:Put*",
"iam:Remove*",
"iam:Resync*",
"iam:Set*",
"iam:Simulate*",
"iam:Update*",
"iam:Put*"
],
"Resource": "*"
}
]}
I figured out an answer that I'm only moderately okay with. I accomplished this by denying every IAM action except the ability to change password and see the password requirements.
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"*"
],
"Resource": [
"*"
]
},
{
"Effect": "Deny",
"Action": [
"iam:AddRoleToInstanceProfile",
"iam:AddUserToGroup",
"iam:AddClientIDToOpenIDConnectProvider",
"iam:AttachGroupPolicy",
"iam:AttachRolePolicy",
"iam:AttachUserPolicy",
"iam:CreateAccessKey",
"iam:CreateAccountAlias",
"iam:CreateGroup",
"iam:CreateInstanceProfile",
"iam:CreateLoginProfile",
"iam:CreateOpenIDConnectProvider",
"iam:CreatePolicy",
"iam:CreatePolicyVersion",
"iam:CreateRole",
"iam:CreateSAMLProvider",
"iam:CreateUser",
"iam:CreateVirtualMFADevice",
"iam:DeactivateMFADevice",
"iam:DeleteAccessKey",
"iam:DeleteAccountAlias",
"iam:DeleteAccountPasswordPolicy",
"iam:DeleteGroup",
"iam:DeleteGroupPolicy",
"iam:DeleteInstanceProfile",
"iam:DeleteLoginProfile",
"iam:DeleteOpenIDConnectProvider",
"iam:DeletePolicy",
"iam:DeletePolicyVersion",
"iam:DeleteRole",
"iam:DeleteRolePolicy",
"iam:DeleteSAMLProvider",
"iam:DeleteSSHPublicKey",
"iam:DeleteServerCertificate",
"iam:DeleteSigningCertificate",
"iam:DeleteUser",
"iam:DeleteUserPolicy",
"iam:DeleteVirtualMFADevice",
"iam:DetachGroupPolicy",
"iam:DetachRolePolicy",
"iam:DetachUserPolicy",
"iam:EnableMFADevice",
"iam:GenerateCredentialReport",
"iam:GenerateServiceLastAccessedDetails",
"iam:GetAccessKeyLastUsed",
"iam:GetAccountAuthorizationDetails",
"iam:GetAccountSummary",
"iam:GetContextKeysForCustomPolicy",
"iam:GetContextKeysForPrincipalPolicy",
"iam:GetCredentialReport",
"iam:GetGroup",
"iam:GetGroupPolicy",
"iam:GetInstanceProfile",
"iam:GetLoginProfile",
"iam:GetOpenIDConnectProvider",
"iam:GetPolicy",
"iam:GetPolicyVersion",
"iam:GetRole",
"iam:GetRolePolicy",
"iam:GetSAMLProvider",
"iam:GetSSHPublicKey",
"iam:GetServerCertificate",
"iam:GetServiceLastAccessedDetails",
"iam:GetServiceLastAccessedDetailsWithEntities",
"iam:GetUser",
"iam:GetUserPolicy",
"iam:ListAccessKeys",
"iam:ListAccountAliases",
"iam:ListAttachedGroupPolicies",
"iam:ListAttachedRolePolicies",
"iam:ListAttachedUserPolicies",
"iam:ListEntitiesForPolicy",
"iam:ListGroupPolicies",
"iam:ListGroups",
"iam:ListGroupsForUser",
"iam:ListInstanceProfiles",
"iam:ListInstanceProfilesForRole",
"iam:ListMFADevices",
"iam:ListOpenIDConnectProviders",
"iam:ListPolicies",
"iam:ListPoliciesGrantingServiceAccess",
"iam:ListPolicyVersions",
"iam:ListRolePolicies",
"iam:ListRoles",
"iam:ListSAMLProviders",
"iam:ListSSHPublicKeys",
"iam:ListServerCertificates",
"iam:ListSigningCertificates",
"iam:ListUserPolicies",
"iam:ListUsers",
"iam:ListVirtualMFADevices",
"iam:PassRole",
"iam:PutGroupPolicy",
"iam:PutRolePolicy",
"iam:PutUserPolicy",
"iam:RemoveClientIDFromOpenIDConnectProvider",
"iam:RemoveRoleFromInstanceProfile",
"iam:RemoveUserFromGroup",
"iam:ResyncMFADevice",
"iam:SetDefaultPolicyVersion",
"iam:SimulateCustomPolicy",
"iam:SimulatePrincipalPolicy",
"iam:UpdateAccessKey",
"iam:UpdateAccountPasswordPolicy",
"iam:UpdateAssumeRolePolicy",
"iam:UpdateGroup",
"iam:UpdateLoginProfile",
"iam:UpdateOpenIDConnectProviderThumbprint",
"iam:UpdateSAMLProvider",
"iam:UpdateSSHPublicKey",
"iam:UpdateServerCertificate",
"iam:UpdateSigningCertificate",
"iam:UpdateUser",
"iam:UploadSSHPublicKey",
"iam:UploadServerCertificate",
"iam:UploadSigningCertificate"
],
"Resource": [
"*"
]
}
]
}
It works, but I'd love something more concise / future proof.
You can use something like below. Using NotAction. This will deny everything for IAM except whatever you mention in NotAction. You can create user using below, but please do note that you will also have to assign policy/roles so add permissions for those under 'NotAction'. Everything else except actions specified in 'NotAction' will be blocked in IAM console. Another part of policy allows everything in console. So just block IAM while allow everything and certain attributes of IAM.
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "VisualEditor0",
"Effect": "Deny",
"NotAction": [
"iam:CreateUser"
],
"Resource": "arn:aws:iam::*:*"
},
{
"Effect": "Allow",
"Action": "*",
"Resource": "*"
}
]
}
Best regards,
Sanjeev B.
I use the following for Infra admins who don't need access to user/group/policy changes.
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"*"
],
"Resource": [
"*"
]
},
{
"Effect": "Deny",
"Action": [
"iam:AddUserToGroup",
"iam:AddClientIDToOpenIDConnectProvider",
"iam:AttachGroupPolicy",
"iam:AttachRolePolicy",
"iam:AttachUserPolicy",
"iam:CreateGroup",
"iam:CreateLoginProfile",
"iam:CreateOpenIDConnectProvider",
"iam:CreatePolicy",
"iam:CreatePolicyVersion",
"iam:CreateRole",
"iam:CreateSAMLProvider",
"iam:CreateUser",
"iam:DeleteAccountPasswordPolicy",
"iam:DeleteGroup",
"iam:DeleteGroupPolicy",
"iam:DeleteLoginProfile",
"iam:DeleteOpenIDConnectProvider",
"iam:DeletePolicy",
"iam:DeletePolicyVersion",
"iam:DeleteRole",
"iam:DeleteRolePolicy",
"iam:DeleteSAMLProvider",
"iam:DeleteUser",
"iam:DeleteUserPolicy",
"iam:DetachGroupPolicy",
"iam:DetachRolePolicy",
"iam:DetachUserPolicy",
"iam:PutGroupPolicy",
"iam:PutRolePolicy",
"iam:PutUserPolicy",
"iam:RemoveClientIDFromOpenIDConnectProvider",
"iam:RemoveUserFromGroup",
"iam:SetDefaultPolicyVersion",
"iam:UpdateAccountPasswordPolicy",
"iam:UpdateAssumeRolePolicy",
"iam:UpdateGroup",
"iam:UpdateLoginProfile",
"iam:UpdateOpenIDConnectProviderThumbprint",
"iam:UpdateSAMLProvider",
"iam:UpdateUser",
],
"Resource": [
"*"
]
}
]
}
I'm trying to use a Lambda function to trigger an Elastic Transcoder job, but I keep getting this error message:
AccessDeniedException: User: arn:aws:sts::xxx:assumed-role/xxxx/xxx is not authorized to perform: elastictranscoder:CreateJob on resource: arn:aws:elastictranscoder:xxxxx:pipeline/xxxxx
My IAM user policy covers all access requirements:
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "Stmt1465486106000",
"Effect": "Allow",
"Action": [
"logs:CreateLogGroup",
"logs:CreateLogStream",
"logs:GetLogEvents",
"logs:PutLogEvents",
"logs:DescribeLogStreams"
],
"Resource": [
"arn:aws:logs:*:*:*"
]
},
{
"Sid": "1",
"Effect": "Allow",
"Action": [
"s3:Put*",
"s3:ListBucket",
"s3:*MultipartUpload*",
"s3:Get*"
],
"Resource": "*"
},
{
"Sid": "2",
"Effect": "Allow",
"Action": "sns:Publish",
"Resource": "*"
},
{
"Sid": "3",
"Effect": "Deny",
"Action": [
"s3:*Delete*",
"s3:*Policy*",
"sns:*Remove*",
"sns:*Delete*",
"sns:*Permission*"
],
"Resource": "*"
}
]
}
Why am I getting the AccessDeniedException and how can I fix it?
Change your policy to below and then try it will work
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "Stmt1465486106000",
"Effect": "Allow",
"Action": [
"logs:CreateLogGroup",
"logs:CreateLogStream",
"logs:GetLogEvents",
"logs:PutLogEvents",
"logs:DescribeLogStreams"
],
"Resource": [
"arn:aws:logs:*:*:*"
]
},
{
"Sid": "1",
"Effect": "Allow",
"Action": [
"elastictranscoder:*",
"s3:Put*",
"s3:ListBucket",
"s3:*MultipartUpload*",
"s3:Get*"
],
"Resource": "*"
},
{
"Sid": "2",
"Effect": "Allow",
"Action": "sns:Publish",
"Resource": "*"
},
{
"Sid": "3",
"Effect": "Deny",
"Action": [
"s3:*Delete*",
"s3:*Policy*",
"sns:*Remove*",
"sns:*Delete*",
"sns:*Permission*"
],
"Resource": "*"
}
]
}
You dont need to change json by editing.
First of all detect which role you want to edit ?
1-) Click Permisson http://prntscr.com/j1giww
2-) see the role name http://prntscr.com/j1gj6s
3-) go to IAM Roles
4-) select the roles that you see at step 2
5-) edit policy and add Transcoder Full Access ( Or selected access )