Troubles with load balancer

I have a 3 master only nodes sat behind a load balancer in AWS.

If I run:

curl -k -E admin.pem --key admin.key https://<aws_public_ip>:9200/_cluster/health?pretty

I get the normal health response. If I run:

curl -k -E admin.pem --key admin.key https://<route53_cname>/_cluster/health?pretty

I get:

503 Service Temporarily Unavailable

My sg_config.yml:

searchguard:

dynamic:

http:

anonymous_auth_enabled: false

xff:

enabled: true

internalProxies: ‘.*’

remoteIpHeader: ‘x-forwarded-for’

proxiesHeader: ‘x-forwarded-by’

trustedProxies: ‘.*’

authc:

basic_internal_auth_domain:

http_enabled: true

transport_enabled: true

order: 3

http_authenticator:

type: basic

challenge: true

authentication_backend:

type: intern

proxy_auth_domain:

http_enabled: true

transport_enabled: true

order: 2

http_authenticator:

type: proxy

challenge: false

config:

user_header: “x-proxy-user”

roles_header: “x-proxy-roles”

authentication_backend:

type: intern

clientcert_auth_domain:

http_enabled: true

transport_enabled: true

order: 1

http_authenticator:

type: clientcert

config:

username_attribute: cn #optional, if omitted DN becomes username

challenge: false

authentication_backend:

type: intern

I have read the docs for each of the config sections, but I find it very hard to relate that to my specific system, so I’m mostly using trial and error.

What I want is for SG to manage the basic auth for me. I want everything (curl, kibana & logstash) to talk to the load balancer and that just forwards the messages to one of the master nodes.

I am finding the docs lacking in examples.

All these authc declarations were given set in the default file but I don’t understand which one applies to which use case, so I left them all in.

  • Examples of the calls that would be serviced by each section may help

I don’t think I need an authz section for my case, but maybe, and if so I have no idea what the config would be.

Is intern the correct type to use? They are all noop by default.

Your docs here say that the proxy module is deprecated but doesn’t say what it is replaced by. This doc describes the same config but doesn’t mention the deprecation.

I am finding it very difficult to get this going and from reading many of the forum posts I don’t think I’m the only one.

I think the simplest option would be a debug mode where SG acted as though it wasn’t installed and instead returned the full path through its config to the result you would get.

Hi,

first, the 503 you are seeing is most likely not related to Search Guard. Search Guard would not return a 503, that’s a typical loadbalancer code when the target system can not be reached.

If you want to disable all of the Search Guard functionality to see if your base installation works, just disable it:

If this is set to true, then your cluster acts like SG is not installed at all.

Regarding the configuration: Sure, we have examples of all supported authentication and authorization modules in there. We support many different auth/auth modules and combinations, so there is no one demo configuration we could provide. For example, using a JWT as request parameter s very different from Kerberos and Active Directory and is different from using the internal user database with HTTP Basic Authentication.

So the first step is to decide what kind of authentication technology / module you want to use for your use case. This also means to decide where your user information is stored. If you do not have anything like and OpenID or SAML Idp, or an LDAP server, you may want to simply store the user credentials in the internal user database. Next you need to decide where the user credentials when logging in are coming from. I guess in your case you want to use HTTP Basic Authentication.

So you just need this part:

  basic_internal_auth_domain:
    http_enabled: true
    transport_enabled: true
    order: 3
    http_authenticator:
      type: basic
      challenge: true
    authentication_backend:
      type: intern

``

If you do not have any external system for authorization (like LDAP for example), you do not need to configure the authz section at all.

The docs cover all supported authentication and authorization technologies, you just need to refer to the one you are planning to use. You do not need the proxy module since you do not use proxy authentication. You just have your load balancer forward the requests to ES, it does not actually authenticate the user. You just need to make sure that the LB also forwards the HTTP headers (which carry the user credentials) to ES.

···

On Wednesday, October 3, 2018 at 7:49:52 PM UTC+2, Martin wrote:

I have a 3 master only nodes sat behind a load balancer in AWS.

If I run:

curl -k -E admin.pem --key admin.key https://<aws_public_ip>:9200/_cluster/health?pretty

I get the normal health response. If I run:

curl -k -E admin.pem --key admin.key https://<route53_cname>/_cluster/health?pretty

I get:

503 Service Temporarily Unavailable

My sg_config.yml:

searchguard:

dynamic:

http:

anonymous_auth_enabled: false

xff:

enabled: true

internalProxies: ‘.*’

remoteIpHeader: ‘x-forwarded-for’

proxiesHeader: ‘x-forwarded-by’

trustedProxies: ‘.*’

authc:

basic_internal_auth_domain:

http_enabled: true

transport_enabled: true

order: 3

http_authenticator:

type: basic

challenge: true

authentication_backend:

type: intern

proxy_auth_domain:

http_enabled: true

transport_enabled: true

order: 2

http_authenticator:

type: proxy

challenge: false

config:

user_header: “x-proxy-user”

roles_header: “x-proxy-roles”

authentication_backend:

type: intern

clientcert_auth_domain:

http_enabled: true

transport_enabled: true

order: 1

http_authenticator:

type: clientcert

config:

username_attribute: cn #optional, if omitted DN becomes username

challenge: false

authentication_backend:

type: intern

I have read the docs for each of the config sections, but I find it very hard to relate that to my specific system, so I’m mostly using trial and error.

What I want is for SG to manage the basic auth for me. I want everything (curl, kibana & logstash) to talk to the load balancer and that just forwards the messages to one of the master nodes.

I am finding the docs lacking in examples.

All these authc declarations were given set in the default file but I don’t understand which one applies to which use case, so I left them all in.

  • Examples of the calls that would be serviced by each section may help

I don’t think I need an authz section for my case, but maybe, and if so I have no idea what the config would be.

Is intern the correct type to use? They are all noop by default.

Your docs here say that the proxy module is deprecated but doesn’t say what it is replaced by. This doc describes the same config but doesn’t mention the deprecation.

I am finding it very difficult to get this going and from reading many of the forum posts I don’t think I’m the only one.

I think the simplest option would be a debug mode where SG acted as though it wasn’t installed and instead returned the full path through its config to the result you would get.