Kerberos support

[bizybot]

Support for Kerberos

Requirements:

• Single Sign-on for Kibana using Kerberos
• Using Kerberos for REST API clients

RFC: https://tools.ietf.org/html/rfc4559, https://www.ietf.org/rfc/rfc2478.txt

Typical Use case:

• User logs into her desktop with credentials (eg. windows machine in AD domain) get Kerberos ticket from AuthenticationService (TGS, KDC)
• User uses a browser to access web application server secured by Kerberos
• Server rejects the request with HTTP 401 Unauthorized status and HTTP header WWW-Authenticate: Negotiate with the login page
• If the browser supports SPNEGO will request TGS for session ticket for given service principal name HTTP/service@REALM, creates base64 Kerberos SPNEGO token and send it as HTTP header Authorization: Negotiate base64-encoded-kerberos-ticket, else will display the login page to the user
• The server verifies session ticket from the browser, if successful sends HTTP 200 status with final header WWW-Authenticate: , else will return HTTP 401 Unauthorized status
• Browser authenticates server for mutual authentication and displays next page

High-level tasks with priority (P? - Priority levels 0 being the highest priority task):

• P0 As ES Admin, I would like to use Kerberos as an authentication mechanism to protect my data
  • KerberosRealm supporting SPENGO mechanism authentication only
    • Based on the client (Kibana or REST) selects appropriate service keytab completes service login.
      Refer Java Krb5LoginModule
    • After login, creates GSSContext and continues with the SPNEGO authentication.
  • Cache User after authentication avoiding unnecessary calls to AD/LDAP for UPN to user DN and group queries
  • Take care when servers behind proxy verify HTTP header Proxy-support: Session- Based-Authentication
• P0 As ES Admin, I would like to configure KerberosRealm
  • Configure SPN (Service principal name) for ES and Kibana HTTP service
  • Single keytab for multiple SPNs, readonly in config directory.
  • Use krb5.conf to define kerberos config properties. -Djava.security.krb5.conf=
  • Bootstrap checks for stronger settings validations
• P0 As ES Admin, I would like to audit log all authentication, authorization events.
  • Note: This is already done just need to test
• P0 As ES Admin, I would like to use Kerberos with or without AD/LDAP integration
  • Uses LDAP realm configuration if integration is required
• P0 As ES Admin, I would like to have user/user group role mapping
  • We can make use of existing AD/LDAP role mapping settings
• P0 As ES client (Kibana), I would like to use Kerberos SPNEGO to authenticate with ES for SSO
  • Option 1 (Preferred): We could make use of token API (POST /_xpack/security/oauth2/token, DELETE /_xpack/security/oauth2/token) where we use the Kerberos ticket as the password. On successful authentication, the response would be oauth2 token and header WWW-Authenticate: token-for-mutual-auth. On failure returns with HTTP 401 Unauthorized status and HTTP header WWW-Authenticate: Negotiate.
  • Option 2: Separate API for Kibana, ES will use Kibana service principal name for authentication by validating user Kerberos ticket (POST /_xpack/security/kerberos/authenticate). If successful, will return HTTP 200 OK, header WWW-Authenticate: and token generated by token service for future use by Kibana for that user session else returns HTTP 401 Unauthorized. Logout API for invalidating the token ( POST /_xpack/security/kerberos/logout)
  • Kibana acts as a proxy passing on the SPNEGO tokens to ES and responds to the client with appropriate headers as expected in SPNEGO
• P1 As ES client (REST API), I would like to use Kerberos SPENGO to authenticate with ES
  • Uses Elasticsearch principal name for authentication by validating user Kerberos ticket
• P0 As ES ops/developer, I would like Kerberos documentation and How-To guide

Security Considerations:

• Support for channel binding will be considered as future enhancement.

Future:

• Support for Microsoft PAC
• Kerberizing Elastic stack - this is cross team and needs discussions to gather requirements from all teams (Kibana, Beats/Logstash, Clients etc.)

[elasticmachine]

Pinging @elastic/es-security