Movatterモバイル変換

[0]ホーム
URL:

Loading
  1. Elastic Docs/
  2. Deploy and manage/
  3. Users and roles/
  4. Cluster or deployment/
  5. User authentication/
  6. External authentication/
  7. OpenID Connect

Set up OpenID Connect with Azure, Google, or Okta

This page explains how to implement OIDC, from the OAuth client credentials generation to the realm configuration for Elasticsearch and Kibana, with the following OpenID Connect Providers (OPs):

For further detail about configuring OIDC, refer toOpenID Connect authentication

Follow these steps to configure OpenID Connect single sign-on on in Elasticsearch with an Azure OP.

For more information about OpenID connect in Azure, refer toAzure OAuth 2.0 and OpenID documentation.

  1. Configure the OAuth client ID.

    1. Create a new application:

      1. Sign into theAzure Portal and go toEntra (formerly Azure Active Directory). From there, selectApp registrations >New registration to register a new application.

        A screenshot of the Azure Owned Applications tab on the New Registration page

  • Enter aName for your application, for exampleec-oauth2.

  • Select aSupported Account Type according to your preferences.

  • Set theRedirect URI.

    It will typically be<KIBANA_ENDPOINT_URL>/api/security/oidc/callback, where<KIBANA_ENDPOINT_URL> is the base URL for your Kibana instance.

    If you're using Elastic Cloud Hosted, then set this value to<KIBANA_ENDPOINT_URL>/api/security/oidc/callback.

  • SelectRegister.

  • Confirm that your newApplication (client) ID appears in the app details.

  • Create a client ID and secret:

    1. From the application that you created, go toCertificates & secrets and create a new secret underClient secrets >New client secret.

      A screenshot of the Azure Add a Client Secret dialog

  • Provide aDescription, for exampleKibana.

  • Select an expiration for the secret.

  • SelectAdd and copy your newly created client secret for later use.

  • Add your client secretto the Elasticsearch keystore.

    For OIDC, the client secret setting name in the keystore should be in the formxpack.security.authc.realms.oidc.<oidc-realm-name>.rp.client_secret.

  • Configure Elasticsearch with the OIDC realm.

    To learn more about the available endpoints provided by Microsoft Azure, refer to theEndpoints details in the application that you configured.

    A screenshot of the Azure Endpoints dialog with fields for Display Name

    • To configure Elasticsearch for OIDC,update your Elasticsearch user settings with the following configuration:

    xpack.security.authc.realms.oidc.oidc1:  order: 2  rp.client_id: "<Application (client) ID>"  rp.response_type: "code"  rp.requested_scopes: ["openid", "email"]  rp.redirect_uri: "KIBANA_ENDPOINT_URL/api/security/oidc/callback"  op.issuer: "https://login.microsoftonline.com/<Directory (tenant) ID>/v2.0"  op.authorization_endpoint: "https://login.microsoftonline.com/<Directory (tenant) ID>/oauth2/v2.0/authorize"  op.token_endpoint: "https://login.microsoftonline.com/<Directory (tenant) ID>/oauth2/v2.0/token"  op.userinfo_endpoint: "https://graph.microsoft.com/oidc/userinfo"  op.endsession_endpoint: "https://login.microsoftonline.com/<Directory (tenant) ID>/oauth2/v2.0/logout"  rp.post_logout_redirect_uri: "KIBANA_ENDPOINT_URL/security/logged_out"  op.jwkset_path: "https://login.microsoftonline.com/<Directory (tenant) ID>/discovery/v2.0/keys"  claims.principal: email  claim_patterns.principal: "^([^@]+)@YOUR_DOMAIN\\.TLD$"

    Where:

    For organizations with many group memberships

    If you configureclaims.groups to read the list of Azure AD groups from the ID token, be aware that users who belong to many groups may exceed Azure AD’s token size limit. In that case, thegroups claim will be omitted.

    To avoid this, enable theGroups assigned to the application option in Azure Entra (App registrations > Token configuration > Edit groups claim). This setting limits thegroups claim to only those assigned to the application.

    Alternative: If you can’t restrict groups to app-assigned ones, use theMicrosoft Graph Authz plugin for Elasticsearch. It looks up group memberships through Microsoft Graph during authorization, so it continues to work even when thegroups claim is omitted due to overage.

    Refer toGroup overages in the Microsoft Security documentation for more information.

    If you're using Elastic Cloud Enterprise or Elastic Cloud Hosted, and you're using machine learning or a deployment with hot-warm architecture, you must include this configuration in the user settings section for each node type.

  • Create a role mapping.

    The following role mapping for OIDC restricts access to a specific user(firstname.lastname) based on theclaim_patterns.principal email address. This prevents other users on the same domain from having access to your deployment. You can remove the rule or adjust it at your convenience.

    More details are available in ourConfiguring role mappings documentation.

    POST /_security/role_mapping/oidc_kibana{    "enabled": true,    "roles": [ "superuser" ],    "rules" : {      "all" : [        {          "field" : {            "realm.name" : "oidc1"          }        },        {          "field" : {            "username" : [              "<firstname.lastname>"            ]          }        }      ]    },    "metadata": { "version": 1 }}

    If you use an email in theclaim_patterns.principal, you won’t need to add the domain in the role_mapping (for example,firstname.lastname@your_domain.tld should befirstname.lastname).

  • Configure Kibana with the OIDC realm.Update your Kibana user settings with the following configuration:

    xpack.security.authc.providers:  oidc.oidc1:    order: 0    realm: oidc1    description: "Log in with Azure"  basic.basic1:    order: 1

    • Setting up OpenID Connect with Google

    Follow these steps to configure OpenID Connect single sign-on on in Elasticsearch with a Google OP.

    For more information about OpenID connect in Google, refer toGoogle OpenID Connect documentation.

    1. Configure the OAuth client ID.

      1. Create a new project:

        1. Sign in to the Google Cloud and open theNew Project page. Create a new project.

      2. Create a client ID and secret:

        1. Navigate to theAPIs & Services and open theCredentials tab to create your OAuth client ID.

          A screenshot of the Google Cloud console Create Credentials dialog with the OAuth client ID field highlighted

  • ForApplication Type chooseWeb application.

  • Choose aName for your OAuth 2 client, for exampleec-oauth2.

  • Add anAuthorized redirect URI.

    It will typically be<KIBANA_ENDPOINT_URL>/api/security/oidc/callback, where<KIBANA_ENDPOINT_URL> is the base URL for your Kibana instance.

    If you're using Elastic Cloud Hosted, then set this value to<KIBANA_ENDPOINT_URL>/api/security/oidc/callback.

  • SelectCreate and copy your client ID and your client secret for later use.

  • Add your client secretto the Elasticsearch keystore.

    For OIDC, the client secret setting name in the keystore should be in the formxpack.security.authc.realms.oidc.<oidc-realm-name>.rp.client_secret.

  • Configure Elasticsearch with the OIDC realm.

    To learn more about the endpoints provided by Google, refer to thisOpenID configuration.

    To configure Elasticsearch for OIDC,update your Elasticsearch user settings with the following configuration:

    xpack.security.authc.realms.oidc.oidc1:  order: 2  rp.client_id: "YOUR_CLIENT_ID"  rp.response_type: "code"  rp.requested_scopes: ["openid", "email"]  rp.redirect_uri: "<KIBANA_ENDPOINT_URL>/api/security/oidc/callback"  op.issuer: "https://accounts.google.com"  op.authorization_endpoint: "https://accounts.google.com/o/oauth2/v2/auth"  op.token_endpoint: "https://oauth2.googleapis.com/token"  op.userinfo_endpoint: "https://openidconnect.googleapis.com/v1/userinfo"  op.jwkset_path: "https://www.googleapis.com/oauth2/v3/certs"  claims.principal: email  claim_patterns.principal: "^([^@]+)@YOUR_DOMAIN\\.TLD$"

    Where:

    If you're using Elastic Cloud Enterprise or Elastic Cloud Hosted, and you're using machine learning or a deployment with hot-warm architecture, you must include this configuration in the user settings section for each node type.

  • Create a role mapping.

    The following role mapping for OIDC restricts access to a specific user(firstname.lastname) based on theclaim_patterns.principal email address. This prevents other users on the same domain from having access to your deployment. You can remove the rule or adjust it at your convenience.

    More details are available in ourConfiguring role mappings documentation.

    POST /_security/role_mapping/oidc_kibana{    "enabled": true,    "roles": [ "superuser" ],    "rules" : {      "all" : [        {          "field" : {            "realm.name" : "oidc1"          }        },        {          "field" : {            "username" : [              "<firstname.lastname>"            ]          }        }      ]    },    "metadata": { "version": 1 }}

    If you use an email in theclaim_patterns.principal, you won’t need to add the domain in the role_mapping (for example,firstname.lastname@your_domain.tld should befirstname.lastname).

  • Configure Kibana with the OIDC realm.Update your Kibana user settings with the following configuration:

    xpack.security.authc.providers:  oidc.oidc1:    order: 0    realm: oidc1    description: "Log in with Google"  basic.basic1:    order: 1

    • Setting up OpenID Connect with Okta

    Follow these steps to configure OpenID Connect single sign-on on for Elasticsearch with an Okta OP.

    For more information about OpenID connect in Okta, refer toOkta OAuth 2.0 documentation.

    1. Configure the OAuth client ID.

      1. Create a new application:

        1. Go toApplications >Add Application.

          A screenshot of the Get Started tab on the Okta Create A New Application page

  • For thePlatform page settings, selectWeb thenNext.

  • In theApplication settings choose aName for your application, for exampleKibana OIDC.

  • Set theBase URI toKIBANA_ENDPOINT_URL.

  • Set theLogin redirect URI.

    It will typically be<KIBANA_ENDPOINT_URL>/api/security/oidc/callback.

    If you're using Elastic Cloud Hosted, then set this value to<KIBANA_ENDPOINT_URL>/api/security/oidc/callback.

  • Set theLogout redirect URI asKIBANA_ENDPOINT_URL/security/logged_out.

  • ChooseDone and copy your client ID and client secret values for later use.

  • Add your client secretto the Elasticsearch keystore.

    For OIDC, the client secret setting name in the keystore should be in the formxpack.security.authc.realms.oidc.<oidc-realm-name>.rp.client_secret.

  • Configure Elasticsearch with the OIDC realm.

    To learn more about the available endpoints provided by Okta, refer to the following OpenID configuration:https://{{yourOktadomain}}/.well-known/openid-configuration

    To configure Elasticsearch for OIDC,update your Elasticsearch user settings with the following configuration:

    xpack.security.authc.realms.oidc.oidc1:  order: 2  rp.client_id: "YOUR_CLIENT_ID"  rp.response_type: "code"  rp.requested_scopes: ["openid", "email"]  rp.redirect_uri: "KIBANA_ENDPOINT_URL/api/security/oidc/callback"  op.issuer: "https://<YOUR_OKTA_DOMAIN>"  op.authorization_endpoint: "https://<YOUR_OKTA_DOMAIN>/oauth2/v1/authorize"  op.token_endpoint: "https://<YOUR_OKTA_DOMAIN>/oauth2/v1/token"  op.userinfo_endpoint: "https://<YOUR_OKTA_DOMAIN>/oauth2/v1/userinfo"  op.endsession_endpoint: "https://<YOUR_OKTA_DOMAIN>/oauth2/v1/logout"  op.jwkset_path: "https://<YOUR_OKTA_DOMAIN>/oauth2/v1/keys"  claims.principal: email  claim_patterns.principal: "^([^@]+)@YOUR_DOMAIN\\.TLD$"

    Where:

    • Remember to add this configuration for each node type in theUser settings if you use several node types based on your deployment architecture (Dedicated Master, High IO, and/or High Storage).

    1. Create a role mapping.

      The following role mapping for OIDC restricts access to a specific user(firstname.lastname) based on theclaim_patterns.principal email address. This prevents other users on the same domain from having access to your deployment. You can remove the rule or adjust it at your convenience.

      More details are available in ourConfiguring role mappings documentation.

      POST /_security/role_mapping/oidc_kibana{    "enabled": true,    "roles": [ "superuser" ],    "rules" : {      "all" : [        {          "field" : {            "realm.name" : "oidc1"          }        },        {          "field" : {            "username" : [              "<firstname.lastname>"            ]          }        }      ]    },    "metadata": { "version": 1 }}

      If you use an email in theclaim_patterns.principal, you won’t need to add the domain in the role_mapping (for example,firstname.lastname@your_domain.tld should befirstname.lastname).

    2. Configure Kibana with the OIDC realm.Update your Kibana user settings with the following configuration:

      xpack.security.authc.providers:  oidc.oidc1:    order: 0    realm: oidc1    description: "Log in with Okta"  basic.basic1:    order: 1
    [8]ページ先頭
    ©2009-2026 Movatter.jp