I'm following this guide (Method 1, step 5) in order to configure Let's Encrypt wildcard certification to my domain, which is controlled by Lightsail DNS.
Making sure all the previous steps have been successfully completed, I am still facing in issue with the fifth-step, where generating the certifications apparently lacks authorization. I made the user to AWS IAM service, as was guided, with a custom permission rule that should suffice, according to the docs:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"lightsail:DeleteDomainEntry",
"lightsail:CreateDomainEntry"
],
"Resource": "<Lightsail DNS zone ARN>"
}
]
}
The error message I get bounced with reads as follows:
Message_: User: arn:aws:iam::MY_USER_ID:user/Certbot is not authorized to perform: lightsail:CreateDomainEntry on resource: arn:aws:lightsail:us-east-1:MY_USER_ID:* because no identity-based policy allows the lightsail:CreateDomainEntry action
Note: I have tried to use the full arn path pointing to my domain directly, but decided to give the wildcard selection a go - no luck there, though.
I also tried to simulate these user roles within IAM, but the actions are denied there as well (Implicitly denied, no matching statements).
Any idea why this is, and what could I do to make this pass? Didn't manage to find any answers related to this issue neither, so now I'm here. I have tried this process with a different IAM user, with full administrative privilidges, and no issues what so ever. But as this is very risky and not ideal at all, I would like to get this to work with the so called "minimum privlidges".
Any help is greatly appreciated!
Related
I'm running a tech stack of react -> graphQL -> appsync -> lambda -> go
When I run my graphQL query from the client I recieve this error back:
Unable to assume role arn:aws:iam::<SOMENUMBER>:role/service-role/MyRoleForMyLambda.
In fact this was all running fine until I accidentally changed the function ARN and roles on my Datasource to other ones. I changed them back but now Appsync seems to be unable to find the role and function ARN. I tried creating a completely new Datasource but I have the same issue. Often the function ARN and/or roles don't appear in the dropdown and I enter them manually. Sometimes it lets me save without errors - other times when attempting to save the Datasource I get the helpful error message "Error". Sometimes after saving when I go to look at them again the function ARN field is blank unless I click on the 'not in drop down' link.
I don't think the problem is with my role itself as it appears that appsync can't even assume the role to start with. I've read about trust policies as a solution but I don't know where to put them.
Any help much appreciated.
In your IAM console, you need to add the Appsync service as a trusted entity to the role you are trying to assume
Click edit trust relationship and enter the following:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "appsync.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
I'm attempting to move a suite of end-to-end tests so that they are fully contained within AWS. I've done this through code build and gotten everything running up to the point of running the tests, which invoke an API to reset the database before every test run. I keep running into this error message when the first test attempts to run.
StatusCodeError: 403 - "{\"Message\":\"User: anonymous is not authorized to perform: execute-api:Invoke on resource: arn:aws:execute-api:eu-west-2:*:*"}"
At first, I thought the error was being caused by a lack of permissions on the role that was being used to build everything. I tried adding the correct permissions to IAM Role being used, eventual making them more open than I would like.
"Effect": "Allow",
"Action": [
"execute-api:Invoke",
"execute-api:ManageConnections"
],
"Resource": "arn:aws:execute-api:*:*:*"
Obviously didn't fix things but I did notice that the access advisor shows that the particular policy isn't being accessed.
Next, I went into the resource policy in API Gateway to see if there was something there. I removed some Ip Address conditions that were set up to restrict access to the office's Ip Addresses.
I've look inside of WAF and Shield and can't see anything that would be related to invoking the API. At this point I am at a lost on where my next investigation should start.
Edit
Here's the responce I'm getting back.
"requestId": "********-82f8-11e9-a732-0b550cf3fcd6",
"ip": "*.*.*.*",
"caller": "-",
"user": "-",
"requestTime": "30/May/2019:16:32:50 +0000",
"httpMethod": "GET",
"resourcePath": "/*/ref-data/{proxy+}", "status": "403", "protocol": "HTTP/1.1", "responseLength": "185"
Below are the steps you need to perform.
For API method - Make Auth = IAM
For API resource policy make sure you allow traffic coming from selected IAM role for specific/all methods
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::###############:role/###########"
},
"Action": "execute-api:Invoke",
"Resource": "arn:aws:execute-api:ap-southeast-1:###########:/#########/*/POST/####/####/"
}
]
}
Make sure same IAM role is attached to entities from where this API is being called e.g. EC2 - if your code resides on EC2
Make sure your API calls are not plain curl calls, they are aws sigv4 signed
Hope this works!
In this case it turned out the major blocker was the API gateway IP Restrictions set in the policy were getting in the way. I did not realise that changes made didn't take affect until (re)deployment. Once I did that with updated IP restrictions the API endpoint could be invoked.
Your role's policy which allows execute-api:Invoke appears to be correct, but the error message you provided says User: anonymous is not authorized to perform.... If you're expecting your role to be attempting this action, then something is wrong because your attempting the action with a user named anonymous.
The role that you use to build your stack isn't necessarily the role that is used to execute functions on that stack. I recommend you double check all of your IAM entities throughout and clearly identify and understand what each one is attempting to do. Make sure that whatever is invoking your function is actually the role you want with the correct policy attached.
Hope this helps!
I have set up an EMR cluster with Zeppelin installed on it. I configured Zeppelin with Active Directory authentication and I have associated those AD users with IAM roles. I was hoping to restrict access to specific resources on S3 after logging into zeppelin using the AD credentials. However, it doesn't seem to be respecting the permissions the IAM role has defined. The EMR role has S3 access so I am wondering if that is overriding the permissions or that is actually the only role it cares about in this scenario
Does anyone have any idea?
I'm actually about to try to tackle this problem this week. I will try to post updates as I have some. I know that this is an old post, but I've found so many helpful things on this site that I figured it might help someone else even if doesn't help the original poster.
The question was if anyone has any ideas, and I do have an idea. So even though I'm not sure if it will work yet, I'm still posting my idea as a response to the question.
So far, what I've found isn't ideal for large organizations because it requires some per user modifications on the master node, but I haven't run into any blockers yet for a cluster at the scale that I need it to be. At least nothing that can't be fixed with a few configuration management tool scripts.
The idea is to:
Create a vanilla Amazon EMR cluster
Configure SSL
Configure authentication via Active Directory
(this step is what I am currently on) Configure Zeppelin to use impersonation (i.e. run the actual notebook processes as the authenticated user), which so far seems to require creating a local OS (Linux) user (with a username matching the AD username) for each user that will be authenticating to the Zeppelin UI. Employing one of the impersonation configurations can then cause Zeppelin run the notebooks as that OS user (there are a couple of different impersonation configurations possible).
Once impersonation is working, manually configure my own OS account's ~/.aws/credentials and ~/.aws/config files.
Write a Notebook that will test various access combinations based on different policies that will be temporarily attached to my account.
The idea is to have the Zeppelin notebook processes kick off as the OS user that is named the same as the AD authenticated user, and then have an ~/.aws/credentials and ~/.aws/config file in each users' home directory, hoping that that might cause the connection to S3 to follow the rules that are attached to the AWS account that is associated with the keys in each user's credentials file.
I'm crossing my fingers that this will work, because if it doesn't, my idea for how to potentially accomplish this will become significantly more complex. I'm planning on continuing to work on this problem tomorrow afternoon. I'll try to post an update when I have made some more progress.
One way to allow access to S3 by IAM user/role is to meet these 2 conditions:
Create S3 bucket policy matching S3 resources with IAM user/role. This should be done in S3/your bucket/Permissions/Bucket Policy.
Example:
{
"Version": "2012-10-17",
"Id": "Policy...843",
"Statement": [
{
"Sid": "Stmt...434",
"Effect": "Allow",
"Principal": {
"AWS": [
"arn:aws:iam::<account-id>:user/your-s3-user",
"arn:aws:iam::<account-id>:role/your-s3-role"
]
},
"Action": "s3:*",
"Resource": [
"arn:aws:s3:::target-bucket/*",
"arn:aws:s3:::other-bucket/specific-resource"
]
}
]
}
Allow S3 actions for your IAM user/role. This should be done in IAM/Users/your user/Permissions/Add inline policy. Example:
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "VisualEditor0",
"Effect": "Allow",
"Action": [
"s3:ListAllMyBuckets",
"s3:HeadBucket",
"s3:ListObjects"
],
"Resource": "s3:*"
}
]
}
Please note this might be not the only and/or best way, but it worked for me.
I've been struggling with this for hours and cannot figure it out.
I've created a new user, duplicity, and I made a new bucket called bobs-house, and generated the following policy: (any numbers I'm not sure I should share are xxx'd out)
{
"Version": "2012-10-17",
"Id": "Policyxxx",
"Statement": [
{
"Sid": "Stmtxxx",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::xxx:user/duplicity"
},
"Action": "s3:*",
"Resource": "arn:aws:s3:::bobs-house/*"
}
]
}
I go to the policy simulator, and run some tests. Sure enough, it says I can do whatever I want as user duplicity, but only on bobs-house. If duplicity tries to do anything involving other buckets, it's denied. Great!
Now I fire up my FTP client and connect to s3.amazonaws.com (using Transmit's S3 protocol of course, not FTP protocol), using duplicity's IAM access key and secret key. I get "access denied." I can't figure out what I'm doing wrong. Any help would be appreciated!
EDIT:
Got it, thanks to John's answer below. I can use Transmit to connect and view only that bucket's contents, add files, etc. But duplicity (backup software) is complaining:
PermanentRedirect. The bucket you are attempting to access must be addressed using the specified endpoint. Please send all future requests to this endpoint. bobs-house.s3.amazonaws.com
So I switch the formatting in duplicity's config to:
s3://bops-house.s3.amazonaws.com/test
And then I get this error:
The request signature we calculated does not match the signature you provided. Check your key and signing method.
My access key & secret key are definitely correct.
If you wish to give Amazon S3 permissions to a specific user, it is better to create the policy against the IAM User themselves, rather than the bucket policy.
A bucket policy is good for assigning universal permissions, while a policy in IAM is good for giving permissions to specific Users or Groups of users.
See: User Policy Examples
I have been struggling to figure out how to communicate with the Amazon ES service from my EC2 instances.
The documentation clearly states that the Amazon ES service supports IAM User & Role based access policies. http://docs.aws.amazon.com/elasticsearch-service/latest/developerguide/es-createupdatedomains.html#es-createdomain-configure-access-policies
However, when I have this access policy for my ES domain:
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::123456789:role/my-ec2-role"
},
"Action": "es:*",
"Resource": "arn:aws:es:us-west-2:123456789:domain/myDomain/*"
}
]
}
I can't log into an ec2 instance and run a curl to hit my elasticsearch cluster.
Trying to do a simple curl of the _search API:
curl "http://search-myDomain.es.amazonaws.com/_search"
Produces an authentication error response:
{"Message":"User: anonymous is not authorized to perform: es:ESHttpGet on resource: arn:aws:es:us-west-2:123456789:domain/myDomain/_search"}
Just to be extra safe I put the AmazonESFullAccess Policy on my IAM Role, still doesn't work.
I must be missing something, because being able to programmatically interact with Elasticsearch from ec2 instances that use an IAM Role is essential to getting anything accomplished with the Amazon ES Service.
I also see this contradictory statement in the docs.
IAM-based Policy Example You create IAM-based access policies by
using the AWS IAM console rather than the Amazon ES console. For
information about creating IAM-based access policies, see the IAM
documentation.
That link to IAM documentation, is to the home page of IAM and contains exactly zero information about how to do it. Anyone got a solution for me?
When using IAM service with AWS, you must sign your requests. curl doesn't support signed requests (which consists of hashing the request and adding a parameter to the header of the request). You can use one of their SDK's that has the signing algorithm built in, and then submit that request.
See:
http://docs.aws.amazon.com/elasticsearch-service/latest/developerguide/what-is-amazon-elasticsearch-service.html#signing-requests
You can find the SDKs for popular languages here:
http://aws.amazon.com/tools/
First, you said you can't login to an EC2 instance to curl the ES instance? You can't login? Or you can't curl it from EC2?
I have my Elasticsearch (Service) instance open to the world (with nothing on it) and am able to curl it just fine, without signing. I changed the access policy to test, but unfortunately it takes forever to come back up after changing it...
My policy looks like this:
{ "Version": "2012-10-17", "Statement": [
{
"Sid": "",
"Effect": "Allow",
"Principal": "*",
"Action": "es:*",
"Resource": "arn:aws:es:us-east-1:843348267853:domain/myDomain/*"
},
{
"Sid": "",
"Effect": "Allow",
"Principal": "*",
"Action": "es:*",
"Resource": "arn:aws:es:us-east-1:843348267853:domain/myDomain"
}
]
}
I realize this isn't exactly what you want, but start off with this (open to the world), curl from outside AWS and test it. Then restrict it, that way you're able to isolate the issues.
Also, I think you have an issue with the "Principal" in your access policy. You have your EC2 Role. I understand why you're doing that, but I think the Principal requires a USER, not a role.
See below:
http://docs.aws.amazon.com/elasticsearch-service/latest/developerguide/es-createupdatedomains.html#es-createdomain-configure-access-policies
Principal
Specifies the AWS account or IAM user that is allowed or denied access
to a resource. Specifying a wildcard (*) enables anonymous access to
the domain, which is not recommended. If you do enable anonymous
access, we strongly recommend that you add an IP-based condition to
restrict which IP addresses can submit requests to the Amazon ES
domain.
EDIT 1
To be clear, you added the AmazonESFullAccess policy to the my-ec2-role? If you're going to use IAM access policies, I don't think you can have a resource based policy attached to it (which is what you're doing).
http://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_compare-resource-policies.html
For some AWS services, you can grant cross-account access to your
resources. To do this, you attach a policy directly to the resource
that you want to share, instead of using a role as a proxy. The
resource that you want to share must support resource-based policies.
Unlike a user-based policy, a resource-based policy specifies who (in
the form of a list of AWS account ID numbers) can access that
resource.
Possibly try removing the access policy altogether?
Why you don't create a proxy with elastic ip and allow your proxy to access your ES?
Basically exists three forms that you can limit access in your ES:
Allow everyone
White IP list
Signing the access key and secret key provided by AWS.
I'm using two forms, in my php apps I prefer to use proxy behind the connection to ES and in my nodejs app I prefer to sign my requests using the http-aws-es node module.
It's useful to create a proxy environment because my users needs to access the kibana interface to see some reports and it's possible because they have configured the proxy in their browsers =)
I must recommend to you close the access to your ES indexes, because it's pretty easy to delete them, curl -XDELETE https://your_es_address/index anyone can do it but you can say: "how the others users will get my ES address?" and I will answer you: "Security based in dimness isn't a real security"
My security access policy is basically something like it:
http://pastebin.com/EUKT1ekX
I encountered this issue recently and the root problem is that none of the Amazon SDKs yet support calling Elasticsearch operations like search, put, etc.
The only workaround at the moment is to execute requests directly against the endpoint using signed requests:
http://docs.aws.amazon.com/general/latest/gr/sigv4-signed-request-examples.html
The example here is for calling EC2, but it can be modified to instead call against Elasticsearch. Just modify the "service" value to "es". From there, you have to fill in values for
the endpoint (which is the full URL of your cluster including operation without request parameters)
the host (the part between https:// and your canonical URI like /_status
the canonical uri which is the URI after the first / inclusive (like /_status) but without the query string
the request parameters (everything after ? inclusive)
Note that I've only managed to get this working so far using AWS credentials as the assumption is that you pass in an access key and secret key to the various signing calls (access_key and secret_key in the example). It should be doable using IAM roles but you'll have to call into the security token service first to get temporary credentials that can be used to sign the request. Until you do that, be sure to edit your access policy on the Elasticsearch cluster to allow user creds (user/
you need to sign your request and unfortunately, it is no longer supported by the official elasticsearch library. Check this Github issue (https://github.com/elastic/elasticsearch-js/issues/1182#issuecomment-630641702)
They want to enforce their own cloud solution