基于Kubernetes ElasticSearch Operator部署的Elastic集群与Kibana集成Keycloak作为身份提供商的可行性咨询（无需集群内启用SSL）

好问题！我刚好处理过类似的私有网络集群场景，其实不用在集群内部启用SSL也能实现Keycloak和Kibana的SSO集成，而且完全适配Elastic Operator的部署方式，下面给你拆解具体的思路和可落地的步骤：

核心思路：利用Kibana原生OIDC支持绕开ES集群内配置限制 #

你提到的Elastic Operator无法修改ES的xpack.security预留配置确实是个限制，但幸运的是，Kibana本身支持直接通过OpenID Connect（OIDC）对接身份提供商，不需要依赖ES集群内部的SSL或xpack.security集群级配置。因为你的网关已经做了SSL终止，对外流量是安全的，集群内部私有网络无需额外SSL的场景完全可以覆盖。

具体实现步骤 #

1. 在Keycloak中创建Kibana专属客户端 #

• 登录Keycloak控制台，进入目标Realm，创建一个新的OpenID Connect类型客户端
• 访问类型选择confidential（需要客户端密钥验证）
• 有效重定向URI设置为网关对外的Kibana完整地址，比如https://your-kibana-public-domain.com/*
• 开启Authorization功能，根据需求配置用户角色（比如创建kibana-admin、kibana-viewer等角色并分配给用户）

2. 在Kubernetes中存储Keycloak客户端密钥 #

用Kubernetes Secret来安全存储Keycloak客户端的密钥，避免明文配置：

kubectl create secret generic keycloak-kibana-secret \
  --from-literal=client-secret="your-keycloak-client-secret" \
  -n elastic-system # 替换为你的Elastic Operator部署命名空间

3. 修改Kibana自定义资源（CR）配置 #

通过Elastic Operator的Kibana CR直接配置OIDC参数，不需要修改ES的任何预留设置：

apiVersion: kibana.k8s.elastic.co/v1
kind: Kibana
metadata:
  name: your-kibana-instance
  namespace: elastic-system
spec:
  version: 8.11.0 # 替换为你的Elastic版本
  count: 1
  elasticsearchRef:
    name: your-elastic-cluster # 关联你的ES集群
  config:
    # 适配网关的路径和公网地址
    server.basePath: "/kibana" # 如果网关有路径转发则设置，否则可省略
    server.publicBaseUrl: "https://your-kibana-public-domain.com/kibana"
    # 配置OIDC身份提供商
    xpack.security.authc.providers:
      oidc.keycloak:
        order: 0 # 设置为第一个认证方式，优先使用Keycloak SSO
        realm: "your-keycloak-realm-name"
        client_id: "your-kibana-client-id"
        client_secret: "${KIBANA_KEYCLOAK_CLIENT_SECRET}" # 通过环境变量注入密钥
        discovery_url: "https://your-keycloak-public-domain.com/auth/realms/your-keycloak-realm-name/.well-known/openid-configuration"
        scope: "openid email profile"
        claims.principal: "preferred_username" # 用Keycloak的用户名作为Kibana身份
        claims.groups: "groups" # 同步Keycloak用户组到Kibana
  podTemplate:
    spec:
      containers:
        - name: kibana
          env:
            - name: KIBANA_KEYCLOAK_CLIENT_SECRET
              valueFrom:
                secretKeyRef:
                  name: keycloak-kibana-secret
                  key: client-secret

4. 调整网关Nginx配置（关键） #

确保Nginx反向代理Kibana时保留必要的请求头，让Kibana能正确生成重定向到Keycloak的地址：

location /kibana {
    proxy_pass http://your-kibana-service.elastic-system.svc.cluster.local:5601;
    # 保留转发相关头信息
    proxy_set_header Host $host;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_set_header X-Forwarded-Host $host;
    # 路径重写（如果配置了basePath）
    rewrite ^/kibana/(.*)$ /$1 break;
}

5. 验证集成效果 #

• 应用Kibana CR配置后，等待Kibana Pod重启完成
• 访问网关对外的Kibana地址，会自动跳转到Keycloak登录页面
• 使用Keycloak账号登录后，会自动回到Kibana，并且根据Keycloak的角色映射获得对应的操作权限

注意事项 #

• 如果Keycloak部署在集群外部，建议通过网关的SSL通道访问Keycloak，避免明文传输客户端密钥和用户凭证
• 可以在Kibana的Stack Management > Security > Role Mappings中，把Keycloak的用户组映射到Kibana的内置角色（比如superuser、viewer），实现更细粒度的权限控制
• Elastic Operator部署的Kibana默认已启用xpack.security，无需额外手动开启

备注：内容来源于stack exchange，提问作者user2835131