AWS Trust Policy Has prohibited field Principal - amazon-web-services

I'm trying to create an IAM role and assign it to an EC2 instance according to Attach an AWS IAM Role to an Existing Amazon EC2 Instance by Using the AWS CLI.
The policy looks like below:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "ec2.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
But it gives this error:
This policy contains the following error: Has prohibited field Principal
There is a similar question here but it couldn't fix this issue.
Any help would be appreciated.

Faced the same issue when trying to update the "Trust Relationship" Or same known as "Trust Policy".
"Principal" comes to play only in "Trust Policy". May be by mistake you are updating normal policy falling under the permissions tab. Try updating the policy under "Trust Relationships" tab as below:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": [
"ec2.amazonaws.com",
"lambda.amazonaws.com"
]
},
"Action": "sts:AssumeRole"
}
]
}

The easiest way to create a Service Role is:
Go to the IAM Console
Click Roles
Create new Role
Select an Amazon EC2 service role
Then attach your policies
It will create the trust policy for you.
Please note that the Trust Policy is stored in a separate location to the actual Policy (the bit that assigns permissions). Based upon the error message, it seems like you're putting the trust policy in the normal spot, because Roles don't need a principle (but trust policies do).

write a policy inside bucket --> permissions --> bucket policy --> save
Note: don't write policy in iam console and bucket and cloud-watch regions must be same. other region wont work.
use below policy
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "logs.YOUR-CLOUD-WATCH-REGION.amazonaws.com"
},
"Action": "s3:GetBucketAcl",
"Resource": "arn:aws:s3:::YOUR-BUCKET-NAME"
},
{
"Effect": "Allow",
"Principal": {
"Service": "logs.YOUR-CLOUD-WATCH-REGION.amazonaws.com"
},
"Action": "s3:PutObject",
"Resource": "arn:aws:s3:::YOUR-BUCKET-NAME/*",
"Condition": {
"StringEquals": {
"s3:x-amz-acl": "bucket-owner-full-control"
}
}
}
]
}

Related

sam pipeline bootstrap created an omnipotent role

In the CI/CD section of the AWS SAM tutorial workshop, when I ran
sam pipeline init --bootstrap and went through the configurations, a role was created with this policy:
{
"Version": "2012-10-17",
"Statement": [
{
"Action": "*",
"Resource": "*",
"Effect": "Allow"
}
]
}
Doesn't this grant the role complete permission over my AWS account which is a big no no? Or is it fine because the permission is granted to an AWS service, and not a user?
This is the trust relationship:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "cloudformation.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
Having a role that exists with those permissionsis fine.
When you create a vanilla AWS Account (in other words I am not including those created by enterprise landing zones like Control Tower) it comes with a policy called AdministratorAccess and a role called Administrator.
The best practice is in who or what you allow to use that policy and when.
Roles are preferred over users, since roles provide security credentials. With a user you have durable credentials you need to secure.
In this case you are allowing CloudFormation to assume this role. This makes sense since CloudFormation often needs to be able to create and modify any resources including IAM roles. If you know you will not be creating or modifying IAM resources you can user a more restrictive role (least privilege), for example using the PowerUserAccess policy which looks like this:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"NotAction": [
"iam:*",
"organizations:*",
"account:*"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"iam:CreateServiceLinkedRole",
"iam:DeleteServiceLinkedRole",
"iam:ListRoles",
"organizations:DescribeOrganization",
"account:ListRegions"
],
"Resource": "*"
}
]
}

How to add sagemaker createApp to user profile executionrole?

I created a aws sagemaker user profile using terraform. I tried to launch the sagemaker studio from the user profile but was confronted with this error: SageMaker is unable to use your associated ExecutionRole [arn:aws:iam::xxxxxxxxxxxx:role/sagemaker-workshop-data-ml] to create app. Verify that your associated ExecutionRole has permission for 'sagemaker:CreateApp'. The role has sagemaker full access policy attached to it, but that policy doesn't have the createApp permission which is weird. Are there any policies I can attach to the role with the sagemaker createApp permission, or do I need to attach a policy to the role through terraform?
Make sure your execution role does not have any permission boundaries. By default, the SageMakerFullAccess policy allows create app permissions - see this statement -
{
"Effect": "Allow",
"Action": [
"sagemaker:CreatePresignedDomainUrl",
"sagemaker:DescribeDomain",
"sagemaker:ListDomains",
"sagemaker:DescribeUserProfile",
"sagemaker:ListUserProfiles",
"sagemaker:*App",
"sagemaker:ListApps"
],
"Resource": "*"
},
You can add an inline policy such as below to make sure your role has permissions to create app -
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AllowCreateApp",
"Effect": "Allow",
"Action": "sagemaker:CreateApp",
"Resource": "*"
}
]
}
Are you talking about arn:aws:iam::aws:policy/AmazonSageMakerFullAccess? If you take a look at this policy, you'll find this as one of the statements:
{
"Effect": "Allow",
"Action": [
"sagemaker:CreatePresignedDomainUrl",
"sagemaker:DescribeDomain",
"sagemaker:ListDomains",
"sagemaker:DescribeUserProfile",
"sagemaker:ListUserProfiles",
"sagemaker:DescribeSpace",
"sagemaker:ListSpaces",
"sagemaker:*App",
"sagemaker:ListApps"
],
"Resource": "*"
},
The sagemaker:*App action on "Resource": "*" means that the policy actually does have the sagemaker:CreateApp permission.
It is a common guardrail (even listed in the AWS Whitepaper on "SageMaker Studio Administration Best Practices") to limit notebook access to specific instances, and that guardrail denies on the CreateApp action. And the recommendation in the whitepaper is to control this at the service control policy level (in AWS Organizations, which you may not have visibility into), with this being an example policy:
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "LimitInstanceTypesforNotebooks",
"Effect": "Deny",
"Action": [
"sagemaker:CreateApp"
],
"Resource": "*",
"Condition": {
"ForAnyValue:StringNotLike": {
"sagemaker:InstanceTypes": [
"ml.c5.large",
"ml.m5.large",
"ml.t3.medium",
"system"
]
}
}
}
]
}

AssumingRole is not authorized to perform, even if add the policies strategy

What I am trying to is using my IAM user udagram-xue-dev to assume the role of eksClusterRole. This is my policies configures:
This policy has been add to my IAM user:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "sts:AssumeRole",
"Resource": "arn:aws:iam::111111111111:role/eksClusterRole"
}
]
}
This trust policy has been added to my eskClusterRole:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::111111111111:user/udagram-xue-dev",
"Service": "eks.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
but I still get this problem:
I have read a lot of relevant details about this assuming role problem, but I still can't figure out how to fix it. It seems that they all just need to add these policies, then it'll be OK.
According to your configuration, everything seems to be in place. However, there might be a different policy (permission boundary, service control policy, or another IAM policy applied to the user) that overrides the permissions.
You can test your policies and find out if there’s anything interfering with your permissions using the IAM Policy Simulator.

AWS IAM Role Policy Resource Restriction

I'm relatively new to AWS and am trying to figure out how the role policies work. I've read the AWS documentation, which is very comprehensive, but the policy I'm applying still isn't doing what I expect... let me explain
I'm trying to grant access to a role so that, when it is assumed, it can do stuff with lambda
I've create a role called "deployer".
I've then attached the below policy to that role:
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "1",
"Effect": "Allow",
"Action": "lambda:*"
"Resource": "arn:aws:iam::<account_id>:role/deployer"
}
]
}
My expectation here is that the Policy says... The specified resource (the deployer role) is "Allowed" to do any action with the Lambda service
However, when I switch to that role in the front end, I get the following error in the Lambda dashboard:
You are not authorized to perform: lambda:GetAccountSettings.
The only solution I've found is to wildcard the Resource attribute in the Policy... however that sort of negates the purpose of trying to restrict access to only that role
Example of the Policy that does what I want
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "1",
"Effect": "Allow",
"Action": "lambda:*"
"Resource": "*"
}
]
}
Could someone explain to me what is actually happening here? I've clearly not understood what the Resource attribute is used for... To me that second Policy says any resource can do anything with Lambda...
Thanks
You're attempting to define the role to apply the policy to in the resource attribute - that's not what the resource attribute is for. The resource attribute relates to the Lambda functions you want the user to be able to call.
To assign this policy to a role, simply create the policy as above (defining your Lambda resources appropriately, which could be a wildcard if you really want to apply this to all your Lambda functions) then assign the policy to a role in the IAM console.
See here for more information on defining resources.
Change
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "1",
"Effect": "Allow",
"Action": "lambda:*"
"Resource": "arn:aws:iam::<account_id>:role/deployer"
}
]
}
to
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "1",
"Effect": "Allow",
"Action": "lambda:*"
"Resource": "arn:aws:lambda:<region>:<account_number>:function:my-awesome-lambda-function"
}
]
}

How to Give Amazon SES Permission to Write to Your Amazon S3 Bucket

I want my SES(AWS) can receive emails, so I follow the following tutorial,
http://docs.aws.amazon.com/ses/latest/DeveloperGuide/receiving-email-getting-started-receipt-rule.html
When I am at last step - creating rule, it comes with following error,
Could not write to bucket: "email-receiving"
I google and found this information on (http://docs.aws.amazon.com/ses/latest/DeveloperGuide/receiving-email-permissions.html) can fix the issue.
However, when adding my policy statement, it comes with an error - This policy contains the following error: Has prohibited field Principal For more information about the IAM policy grammar, see AWS IAM Policies.
My policy statement is,
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "GiveSESPermissionToWriteEmail",
"Effect": "Allow",
"Principal": {
"Service": [
"ses.amazonaws.com"
]
},
"Action": [
"s3:PutObject"
],
"Resource": "arn:aws:s3:::mybulketname/*",
"Condition": {
"StringEquals": {
"aws:Referer": "my12accountId"
}
}
}
]
}
If I take off
"Principal": {
"Service": [
"ses.amazonaws.com"
]
}
Validate policy will pass.
Thanks
Find bucket->permission->bucketPolicy
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AllowSESPuts",
"Effect": "Allow",
"Principal": {
"Service": "ses.amazonaws.com"
},
"Action": "s3:PutObject",
"Resource": "arn:aws:s3:::BUCKEN_NAME/*",
"Condition": {
"StringEquals": {
"aws:Referer": "YOUR ID"
}
}
}
]
}
Read more here https://docs.aws.amazon.com/ses/latest/DeveloperGuide/receiving-email-permissions.html
To find your AWS account ID number on the AWS Management Console, choose Support on the navigation bar on the upper-right, and then choose Support Center. Your currently signed-in account ID appears in the upper-right corner below the Support menu.
Read more here https://docs.aws.amazon.com/IAM/latest/UserGuide/console_account-alias.html
I follow this advice but I was still having the issue. After much debugging, I realized that SES was failing to write because I had default server-side encryption (on the bucket) set to "AWS-KMS"
I did a 5 minute google search and couldn't find this incompatibility documented anywhere.
You can work around this by updating your default encryption setting on the target bucket to either "AES-256" or "None".
This problem has been resolved.
Create the policy on the bucket you want to grant the SES permission, not in the IAM
Note, I continued to have this error even after correctly specifying permissions. If you are using cross-region (e.g. SES is in N Virginia and S3 Bucket is in Africa) then you either need to specify the bucket name with the region or else just make the bucket in the same region.
I have the same problem, if I only delete the "Condition"
the policy passes and the "RuleSet" is Ok:
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "GiveSESPermissionToWriteEmail",
"Effect": "Allow",
"Principal": {
"Service": "ses.amazonaws.com"
},
"Action": "s3:PutObject",
"Resource": "arn:aws:s3:::mybulketname/*"
}
]
}