I did not find the solution here so I need to ask you for some help.
I am trying to create a new simple aws policy (cli) with powershell and I have the error:
An error occurred (MalformedPolicyDocument) when calling the
CreatePolicy operation: Syntax errors in policy.
This is the command I use:
aws iam create-policy --policy-name TEST-POLICY --policy-document file://policy.json
And this is the policy.json file:
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "VisualEditor0",
"Effect": "Allow",
"Action": [
"iam:GetUser",
"iam:GetGroup"
],
"Resource": [
"arn:aws:iam::(arn id):user/(arn id)",
"arn:aws:iam::(arn id):group/(arn id)"
]
}
]
}
It is strange because when I use the AWS website JSON editor it works fine. But when I try it on my windows pc does not.
Someone can see the wrong syntax?
Solved. It was because the encoding UTF-8-BOM. It must be UTF-8
Related
everyone. I have a situation in which I want a web application to add / update files to an S3 bucket, and then have only specified IPs be able to read these files. My web application uses AWS SDK to access the S3 bucket and upload files. So, in other words, I want SDK and specified IPs access to the bucket, and otherwise deny access.
I tried doing this through the S3 bucket policy but was unable to make it work. My latest attempt at the policy is as follows:
{
"Version": "2012-10-17",
"Id": "MyPolicy",
"Statement": [
{
"Sid": "MyPolicy",
"Effect": "Deny",
"Principal": "*",
"Action": "s3:*",
"Resource": [
"arn:aws:s3:::my-bucket",
"arn:aws:s3:::my-bucket/*"
],
"Condition": {
"StringNotLike": {
"aws:SourceIp": [
"11.11.11.111/32",
"22.22.22.222/32",
"333.333.33.333/32",
"444.444.44.444/32"
],
"aws:SourceAccount": [
"123456789012"
]
}
}
}
]
}
This did not work, however, as it blocked even the bucket owner / root account from accessing files. Any help is appreciated, thanks in advance!
I am trying to follow this tutorial here to create an execution role - https://docs.aws.amazon.com/lambda/latest/dg/python-package-create.html
However, when I try and run the following command from the instructions
aws iam create-role --role-name lambda-ex --assume-role-policy-document "{"Version": "2012-10-17","Statement": [{ "Effect": "Allow", "Principal": {"Service": "lambda.amazonaws.com"}, "Action": "sts:AssumeRole"}]}"
I get the error "An error occurred (MalformedPolicyDocument) when calling the CreateRole operation: This policy contains invalid Json".
I'm new to AWS so I'm not sure what's going on - can anyone help please?
Use single quotes. Note: this only works for Linux-like OS.
aws iam create-role --role-name lambda-ex --assume-role-policy-document '{"Version": "2012-10-17","Statement": [{ "Effect": "Allow", "Principal": {"Service": "lambda.amazonaws.com"}, "Action": "sts:AssumeRole"}]}'
To fix this, as perjellycsc's advise to escape every " in the string I used:
aws iam create-role --role-name lambda-ex --assume-role-policy-document "{\"Version\": \"2012-10-17\",\"Statement\": [{ \"Effect\": \"Allow\", \"Principal\": {\"Service\": \"lambda.amazonaws.com\"}, \"Action\": \"sts:AssumeRole\"}]}"
I'm currently working on an AWS course, and have been using the Windows CLI in order to setup demo infrastructure in my AWS VPC. I was attempting to create a role called "bastion-role" via using the following command:
aws iam create-role --role-name bastion-role --assume-role-policy-document file://role-policy.json
but it yields this error:
Error parsing parameter --assume-role-policy-document: Unable to
load paramfile file://role-policy.json: [Errno 2] No such file or
directory: 'role-policy.json'
I'm assuming it's having a problem referencing the local directory that I'm currently in. I've attempted the following troubleshooting measures:
Not using the file:// part and just the name 'role-policy.json'. This didn't work
Trying to reference the local directory: file://c:\role-policy-json
Tried a relative path: file://../role-policy.json
Tried using 3 forward slashes: file:///role-policy.json
Tried using 3 forward slashes and local directory: file:///c:\role-policy.json
Unfortunately, none of these combinations have worked. I'm assuming I'm missing something, but I can't figure it out. If someone could shed some light on this problem, I'd appreciate it.
Probably its too late to provide this answer, but the right way to execute this command is like this:
aws iam --region us-east-2 create-role --role-name <YOUR_ROLE_NAME> --assume-role-policy-document file://C:\Users\<USERNAME>\FULL\PATH\TO\file_containing_policy.json
After successful execution you should see something like this:
{
"Role": {
"Path": "/",
"RoleName": "YOUR_ROLE_NAME",
"RoleId": "AROXXXXXXXXXXXXXXXXXX",
"Arn": "arn:aws:iam::XXXXXXXXXXXX:role/YOUR_ROLE_NAME",
"CreateDate": "2020-11-17T04:53:35+00:00",
"AssumeRolePolicyDocument": {
"Version": "2012-10-17",
"Statement": [
{
"Sid": "",
"Effect": "Allow",
"Principal": {
"Service": "<SERVICE>.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
}
}
I've an AWS Api-Gateway resource that I tried configuring to add a message to AWS-SQS, however when I try sending a request to the api I get a response:
{
"Error": {
"Code": "MissingParameter",
"Message": "Version is missing.",
"Type": "Sender"
},
"RequestId": "the-multicharacter-request-id-blah-blah"
}
I have linked the two services in the integration taband the permissions policy is the below:
{
"Version": "2012-10-17",
"Statement": [
{
"Action": [
"sqs:*"
],
"Effect": "Allow",
"Resource": "*"
}
]
}
I've tried adding in api-gateway permissions to the policy, adding a Version parameter in the header, starting the setup from scratch again.
Is there something I'm missing?
'Version' here specifies which version of 'SQS' service to use and should be specified as a query parameter and not the header e.g.:
?Version='2019-05-09'
'Version' specified in the policy refers to the version of the policy language.
This was a case of RTFM.
I ran into this due to a different root cause: make sure the "Action Type" is set to "Use path override" if you don't intent to use "action override"
In my current terraform configuration I am using a static JSON file and importing into terraform using the file function to create an AWS IAM policy.
Terraform code:
resource "aws_iam_policy" "example" {
policy = "${file("policy.json")}"
}
AWS IAM Policy definition in JSON file (policy.json):
{
"Version": "2012-10-17",
"Id": "key-consolepolicy-2",
"Statement": [
{
"Sid": "Enable IAM User Permissions",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::111122223333:root"
},
"Action": "kms:*",
"Resource": "*"
},
{
"Sid": "Allow use of the key",
"Effect": "Allow",
"Principal": {
"AWS": [
"arn:aws:iam::777788889999:root"
]
},
"Action": [
"kms:Decrypt"
],
"Resource": "*"
},
{
"Sid": "Allow use of the key",
"Effect": "Allow",
"Principal": {
"AWS": [
"arn:aws:iam::444455556666:root"
]
},
"Action": [
"kms:Decrypt"
],
"Resource": "*"
}
]
}
My goal is to use a list of account numbers stored in a terraform variable and use that to dynamically build the aws_iam_policy resource in terraform. My first idea was to try and use the terraform jsonencode function. However, it looks like there might be a way to implement this using the new terraform dynamic expressions foreach loop.
The sticking point seems to be appending a variable number of resource blocks in the IAM policy.
Pseudo code below:
var account_number_list = ["123","456","789"]
policy = {"Statement":[]}
for each account_number in account_number_list:
policy["Statement"].append(policy block with account_number var reference)
Any help is appreciated.
Best,
Andrew
The aws_iam_policy_document data source from aws gives you a way to create json policies all in terraform, without needing to import raw json from a file or from a multiline string.
Because you define your policy statements all in terraform, it has the benefit of letting you use looping/filtering on your principals array.
In your example, you could do something like:
data "aws_iam_policy_document" "example_doc" {
statement {
sid = "Enable IAM User Permissions"
effect = "Allow"
actions = [
"kms:*"
]
resources = [
"*"
]
principals {
type = "AWS"
identifiers = [
for account_id in account_number_list:
account_id
]
}
}
statement {
...other statements...
}
}
resource "aws_iam_policy" "example" {
// For terraform >=0.12
policy = data.aws_iam_policy_document.example_doc.json
// For terraform <0.12
policy = "${data.aws_iam_policy_document.example_doc.json}"
}
1st option:
if you don't want to rebuild the policy in aws_iam_policy_document you can use templatefile see https://www.terraform.io/docs/language/functions/templatefile.html
resource "aws_iam_policy" "example" {
policy = templatefile("policy.json",{account_number_list = ["123","456","789"]})
}
...
%{ for account in account_number_list ~}
{
"Sid": "Enable IAM User Permissions",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::${account}:root"
},
"Action": "kms:*",
"Resource": "*"
},
%{ endfor ~}
...
2nd option:
https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_variables.html#policy-vars-infotouse
AWS's IAM policy document syntax allows for replacement of policy
variables within a statement using ${...}-style notation, which
conflicts with Terraform's interpolation syntax. In order to use AWS
policy variables with this data source, use &{...} notation for
interpolations that should be processed by AWS rather than by
Terraform.
...
{
"Sid": "Enable IAM User Permissions",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::&{aws:userid}:root"
},
"Action": "kms:*",
"Resource": "*"
},
Like in: https://registry.terraform.io/providers/hashicorp/aws/latest/docs/data-sources/iam_policy_document
This was great and is a good pattern to be able to hold onto. Unfortunately, I ran into an issue with it going up against the quota limit:
Assume Role Policy: LimitExceeded: Cannot exceed quota for ACLSizePerRole: 2048
You can request an increase on this quota size but supposedly the max is 4098. the assume role policy I am attempting to create is needed for every AWS account we have so we will eventually hit that limit as well.
It's unfortunate that you can use wild cards within arns of an assume role policy but you can use "*" which I would argue is much much riskier.