cloud-on-k8s
cloud-on-k8s copied to clipboard
Document OIDC setup
We could introduce a page that covers the diff between https://www.elastic.co/guide/en/elasticsearch/reference/current/oidc-guide.html and how it is done on Kubernetes. I think it is only the mounting of configuration files in a Pod through Secrets and ConfigMaps but it might still be helpful for some users.
@pebrc Would we be able to revisit this? Haven't found consistent documentation on how this structure is passed into the helm charts. If we could standardize in this area, that would be awesome
@naemono Would it be beneficial to add documentation on this to the Elasticsearch and Kibana helm charts or docs directory?
Such as:
nodeSets:
- name: master
count:
config:
xpack:
security:
audit:
enabled: true
authc:
realms:
oidc:
oidc1:
claims:
groups:
principal:
op:
authorization_endpoint:
endsession_endpoint:
issuer:
userinfo_endpoint:
jwkset_path:
token_endpoint:
order: 2
rp:
client_id:
post_logout_redirect_uri:
redirect_uri:
requested_scopes:
response_type:
token.enabled:
@RoseSecurity This would be helpful as I am running into issues setting the xpack.security.authc.realms.oidc.oidc1.rp.client_secret in the elasticsearch.yml. Without that setting the elasticsearch pod fails to startup saying that it is required and with that setting it fails saying it must be set inside the Elasticsearch keystore.
The oidc-guide recommends using the elasticsearch-keystore binary to configure the client_secret but it is not clear how to do that with the kubernetes deployment, perhaps through a new or existing init container?
@RoseSecurity - I was able to successfully set xpack.security.authc.realms.oidc.oidc1.rp.client_secret by creating the following secret:
kubectl create secret generic eck-keycloak-client-secret --from-literal=xpack.security.authc.realms.oidc.oidc1.rp.client_secret=<secret-id> -n elastic-stack
then adding the following value override:
secureSettings:
- secretName: eck-keycloak-client-secret
nodeSets:
...
May be worth documenting as part of this effort if it isn't already.
Totally agree, I encountered this a few months ago and saw limited documentation on it; would appreciate if it was picked up by someone on the Elastic team as I don't have good enough context on the internals to write it.