User: anonymous is not authorized to perform: es:ESHttpPost on resource:

Question

I'm having this issue with my app. my app is deployed to Heroku server, and i'm using Elasticsearch which is deployed on AWS. when i try to access locally to Elasticsearch - on aws domain - everyting works. but,when i try to access to my Heroku domain (both from postman) i get 503 error with this message :

2017-12-21T13:36:52.982331+00:00 app[web.1]:   statusCode: 403,
2017-12-21T13:36:52.982332+00:00 app[web.1]:   response: '{"Message":"User: anonymous is not authorized to perform: es:ESHttpPost on resource: houngrymonkey"}',

my access policy is :

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "*"
      },
      "Action": "es:*",
      "Resource": "arn:aws:es:eu-central-1:[ACCOUNT_ID]:domain/[ES_DOMAIN]/*",
      "Condition": {
        "IpAddress": {
          "aws:SourceIp": "[heroku static ip]"
        }
      }
    }
  ]
}

can anyone tell me what is my problem here? thanks!

Solution 1

I've experienced the same issue with ES and lambda, it's not exactly your case, but maybe it'll be helpful.What actually I did to resolve the issue

1) in lambda (Node.js v6.10) I added the following code:

var creds = new AWS.EnvironmentCredentials('AWS');
....
// inside "post to ES"-method
var signer = new AWS.Signers.V4(req, 'es');
signer.addAuthorization(creds, new Date());
....
// post request to ES goes here

With those lines my exception changed from "User: anonymous..." to "User: arn:aws:sts::xxxx:assumed-role/yyyy/zzzzz" That was exactly the case.

2) I've updated ES policy in the following way

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:sts::xxxx:assumed-role/yyyy/zzzzz" (which was in exception)
      },
      "Action": "es:*",
      "Resource": "arn:aws:es:[region]:[account-id]:domain/[es-domain]/*"
    },
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "*"
      },
      "Action": "es:*",
      "Resource": "arn:aws:es:[region]:[account-id]:domain/[es-domain]/*"
      "Condition": {
        "IpAddress": {
          "aws:SourceIp": [
            "1.2.3.4/32",
            ....
          ]
        }
      }
    }
  ]
}

Hope that will help.

Solution 2

More solutions to the error mentioned in title are described here:

If you are using a client that doesn't support request signing (such as a browser), consider the following:

1. Use an IP-based access policy. IP-based policies allow unsigned requests to an Amazon ES domain.
2. Be sure that the IP addresses specified in the access policy use CIDR notation. Access policies use CIDR notation when checking IP address against the access policy.
3. Verify that the IP addresses specified in the access policy are the same ones used to access your Elasticsearch cluster. You can get the public IP address of your local computer at https://checkip.amazonaws.com/.

Note: If you're receiving an authorization error, check to see if you are using a public or private IP address. IP-based access policies can't be applied to Amazon ES domains that reside within a virtual private cloud (VPC). This is because security groups already enforce IP-based access policies. For public access, IP-based policies are still available. For more information, see About access policies on VPC domains.

If you are using a client that supports request signing, check the following:

1. Be sure that your requests are correctly signed. AWS uses the Signature Version 4 signing process to add authentication information to AWS requests. Requests from clients that aren't compatible with Signature Version 4 are rejected with a "User: anonymous is not authorized" error. For examples of correctly signed requests to Amazon ES, see Making and signing Amazon ES requests.

2. Verify that the correct Amazon Resource Name (ARN) is specified in the access policy.

If your Amazon ES domain resides within a VPC, configure an open access policy with or without a proxy server. Then, use security groups to control access. For more information, see About access policies on VPC domains.

Comments

[Oleksandr Oliynyk]

daysaver, thanks!