opensearch-project / security

🔐 Secure your cluster with TLS, numerous authentication backends, data masking, audit logging as well as role-based access control on indices, documents, and fields
https://opensearch.org/docs/latest/security-plugin/index/
Apache License 2.0
197 stars 275 forks source link

[FEATURE] Allow LDAP groups to impersonate users #3762

Open spapadop opened 11 months ago

spapadop commented 11 months ago

Is your feature request related to a problem?

I have integrated LDAP for authentication and authorisation in my OpenSearch clusters. Each cluster is "managed" by a different LDAP group, that are acting as superadmins (i.e. essentially they are mapped to the "all_access" role, through backend_role).

Now, reading the official doc I thought of giving an LDAP group the possibility to impersonate users in my cluster.

So, I add this on my opensearch.yml config, hoping that besides user "joe", all people in "it-opensearch-administrators" LDAP group will be able to impersonate every user in the cluster.

plugins.security.authcz.rest_impersonation_user.admin:
- "*"
plugins.security.authcz.impersonation_dn:
  "CN=it-opensearch-administrators,OU=e-groups,OU=Workgroups,DC=mydomain,DC=com":
  - "*"

authenticating (using basic auth) and impersonating any user with user "admin" works as expected.

and then I try this (authenticating through kerberos) with a user "joe" who is member of "it-opensearch-administrators" LDAP group:

curl --negotiate -u : -k -H "opendistro_security_impersonate_as: paok" https://mycluster.mydomain.com/_cluster/health?pretty

I get this:

{
  "error" : {
    "root_cause" : [
      {
        "type" : "security_exception",
        "reason" : "'joe' is not allowed to impersonate as 'paok'"
      }
    ],
    "type" : "security_exception",
    "reason" : "'joe' is not allowed to impersonate as 'paok'"
  },
  "status" : 403
}

What solution would you like? I would like to be able to give impersonation rights to an LDAP group dynamically, so that any user of the organisation that is member of that group (which changes over time), automatically gets impersonation rights over other users.

What alternatives have you considered? Setting up an internal_user for each cluster and let them use that for impersonation. But that's a work-around more than a solution to the problem.

Do you have any additional context? Here's my entire config.yml, in case it helps.

_meta:
  type: "config"
  config_version: 2

config:
  dynamic:
    http:
      anonymous_auth_enabled: false
      xff:
    enabled: false
        internalProxies: '192\.168\.0\.10|192\.168\.0\.11' # regex pattern

    kibana:
      multitenancy_enabled: true
      server_username: iteskibanauser
      index: '.kibana'
    do_not_fail_on_forbidden: true

    authc:
      basic_internal_auth_domain:
        description: "Authenticate via HTTP Basic against internal users database"
        http_enabled: true
        transport_enabled: true
        order: 1
        http_authenticator:
          type: basic
          challenge: false
        authentication_backend:
          type: intern
      openid_auth_domain:
        description: "Authenticate via OpenID Connect"
        http_enabled: true
        transport_enabled: true
        order: 0
        http_authenticator:
          type: openid
          challenge: false
          config:
            subject_key: preferred_username
            openid_connect_url: 'https://keycloak.mydomain.com/auth/realms/mydomain/.well-known/openid-configuration'
            skip_users:
            - iteskibanauser
        authentication_backend:
          type: noop
      ldap_auth_domain:
        description: "Authenticate via LDAP or Active Directory"
        http_enabled: true
        transport_enabled: true
        order: 2
        http_authenticator:
          type: basic
          challenge: false
        authentication_backend:
          type: ldap
          config:
            enable_ssl: false
            enable_start_tls: false
            enable_ssl_client_auth: false
            verify_hostnames: true
            hosts:
            - xldap.mydomain.com:389
            bind_dn: null
            password: null
            userbase: 'OU=Users,OU=Organic Units,DC=mydomain,DC=com'
            usersearch: '(sAMAccountName={0})'
            username_attribute: 'cn'
      kerberos_auth_domain:
        description: "Authenticate via Kerberos"
        http_enabled: true
        transport_enabled: true
        order: 3
        http_authenticator:
          type: kerberos
          challenge: true
          config:
            krb_debug: false
            strip_realm_from_principal: true
        authentication_backend:
          type: noop

    authz:
      roles_from_myldap:
        description: "Authorize via LDAP or Active Directory"
        http_enabled: true
        transport_enabled: false
        authorization_backend:
          type: ldap
          config:
            enable_ssl: false
            enable_start_tls: false
            enable_ssl_client_auth: false
            verify_hostnames: true
            hosts:
            - xldap.mydomain.com:389
            bind_dn: null
            password: null
            userbase: 'OU=Users,OU=Organic Units,DC=mydomain,DC=com'
            usersearch: '(sAMAccountName={0})'
            username_attribute: 'cn'
            rolebase: 'OU=Unix,OU=Workgroups,DC=mydomain,DC=com'
            rolesearch: '(member={0})'
            userroleattribute: null
            userrolename: 'memberOf'
            rolename: 'cn'
            resolve_nested_roles: true
            skip_users:
            - iteskibanauser
cwperks commented 11 months ago

[Triage] Thank you for filing this issue and providing details @spapadop.