Closed djschny closed 5 years ago
As you've noticed, it's not currently possible to configure the password of the elastic
user. It's defined in the file realm which is managed by the operator internally. The only thing that can currently be done with the elastic
user is to reset the password to a new random one by deleting the <cluster-name>-es-elastic-user
Secret.
Would using those credentials once to create a new user (in the native realm) work for you? E.g along the lines of:
$ AUTH=elastic:$(kubectl get secret testing-es-elastic-user -o=go-template='{{ .data.elastic | base64decode }}')
$ curl -k -XPOST -u $AUTH https://localhost:9200/_security/user/my-user -H 'Content-Type: application/json' -d '{
"password":"my-password",
"roles":["superuser"]
}'
{"created":true}
$ curl -k -u my-user:my-password https://localhost:9200
{
"name" : "testing-es-2qvmzzn9sl",
"cluster_name" : "testing",
...
"tagline" : "You Know, for Search"
}
Actually it's possible to set the password to a well known value by creating the {clusterName}-es-elastic-user
Secret before creating the Elasticsearch resource:
$ kubectl create secret generic testing-es-elastic-user --from-literal=elastic=foobar
secret/testing-es-elastic-user created
$ cat <<'EOFTEST' | kubectl apply -f -
apiVersion: elasticsearch.k8s.elastic.co/v1alpha1
kind: Elasticsearch
metadata:
name: testing
spec:
version: 7.1.0
nodes:
- nodeCount: 1
EOFTEST
elasticsearch.elasticsearch.k8s.elastic.co/testing configured
$ # set up any forwarding you need after the ES pod is done initializing, e.g in another terminal:
$ kubectl port-forward service/testing-es 9200:9200
$ curl -k -u elastic:foobar https://localhost:9200
{
"name" : "testing-es-5ps8sl8sfn",
"cluster_name" : "testing",
...
"tagline" : "You Know, for Search"
}
Thanks to @agup006 for pointing this one out to me.
I would file this under "workaround" for now, and not an officially supported feature.
Wonderful @nkvoll and @agup006, this works great!
This PR has been merged, so in the future after its release we'll be able to specify a custom creation of user & password in a secret file, so that should satisfy your use case.
Does the PR above creates a complementary mechanism for the {{ cluster-name }}-es-elastic-user
secret creation? I mean this super user defined in {{ cluster-name }}-es-elastic-user
is going to be created either way, right?
Does the PR above creates a complementary mechanism for the
{{ cluster-name }}-es-elastic-user
secret creation?
You provide and reference secrets in the Elasticsearch resource containing custom users and roles, see the documentation: https://www.elastic.co/guide/en/cloud-on-k8s/current/k8s-users-and-roles.html#k8s_file_realm.
I mean this super user defined in
{{ cluster-name }}-es-elastic-user
is going to be created either way, right?
Yes!
Τhanks @thbkrkr .
So I assume there is no way foreseen to rotate this (say in case of a security incident) without destroying / recreating the cluster?
Or will creating a new {{ cluster-name }}-es-elastic-user
cause a smooth rolling update with replacement of the old one?
I was considering using an init
container to create the secret (with the appropriate RBAC permissions of course) but I don't know this would work out in case of a rolling update, since at some point pods with the old and new password will co-exist
So I assume there is no way foreseen to rotate this (say in case of a security incident) without destroying / recreating the cluster? Or will creating a new
{{ cluster-name }}-es-elastic-user
cause a smooth rolling update with replacement of the old one?
Maybe this section in the documentation could help ?
@barkbay yes that was really helpful.
Thanks.
not help
root@node52:~# kubectl -n elastic-system logs -f kibana-kb-68cd5bf5d5-kqbmq -c kibana
[2023-01-06T01:33:15.918+00:00][INFO ][node] Kibana process configured with roles: [background_tasks, ui]
[2023-01-06T01:37:04.607+00:00][INFO ][http.server.Preboot] http server running at https://0.0.0.0:5601
[2023-01-06T01:37:04.734+00:00][INFO ][plugins-system.preboot] Setting up [1] plugins: [interactiveSetup]
[2023-01-06T01:37:04.824+00:00][WARN ][config.deprecation] The default mechanism for Reporting privileges will work differently in future versions, which will affect the behavior of this cluster. Set "xpack.reporting.roles.enabled" to "false" to adopt the future behavior before upgrading.
[2023-01-06T01:37:05.069+00:00][INFO ][plugins-system.standard] Setting up [121] plugins: [translations,monitoringCollection,licensing,globalSearch,globalSearchProviders,features,mapsEms,licenseApiGuard,usageCollection,taskManager,telemetryCollectionManager,telemetryCollectionXpack,kibanaUsageCollection,share,embeddable,uiActionsEnhanced,screenshotMode,banners,newsfeed,fieldFormats,expressions,dataViews,charts,esUiShared,customIntegrations,home,searchprofiler,painlessLab,grokdebugger,management,advancedSettings,spaces,security,lists,encryptedSavedObjects,cloud,snapshotRestore,screenshotting,telemetry,licenseManagement,eventLog,actions,console,bfetch,data,watcher,reporting,fileUpload,ingestPipelines,alerting,unifiedSearch,savedObjects,graph,savedObjectsTagging,savedObjectsManagement,presentationUtil,expressionShape,expressionRevealImage,expressionRepeatImage,expressionMetric,expressionImage,controls,eventAnnotation,dataViewFieldEditor,triggersActionsUi,transform,stackAlerts,ruleRegistry,discover,fleet,indexManagement,remoteClusters,crossClusterReplication,indexLifecycleManagement,cloudSecurityPosture,discoverEnhanced,aiops,visualizations,canvas,visTypeXy,visTypeVislib,visTypeVega,visTypeTimeseries,rollup,visTypeTimelion,visTypeTagcloud,visTypeTable,visTypeMetric,visTypeHeatmap,visTypeMarkdown,dashboard,dashboardEnhanced,expressionXY,expressionTagcloud,expressionPartitionVis,visTypePie,expressionMetricVis,expressionLegacyMetricVis,expressionHeatmap,expressionGauge,lens,osquery,maps,dataVisualizer,ml,cases,timelines,sessionView,kubernetesSecurity,securitySolution,visTypeGauge,sharedUX,observability,synthetics,infra,upgradeAssistant,monitoring,logstash,enterpriseSearch,apm,dataViewManagement]
[2023-01-06T01:37:05.090+00:00][INFO ][plugins.taskManager] TaskManager is identified by the Kibana UUID: 7e6ab156-eb00-4454-a5ea-1ae130ebc5c4
[2023-01-06T01:37:05.210+00:00][INFO ][plugins.encryptedSavedObjects] Hashed 'xpack.encryptedSavedObjects.encryptionKey' for this instance: NFTZ1s9jpN0wZSDfjF/oIStb4gR84NLZbkMNr+AEjjg=
[2023-01-06T01:37:05.344+00:00][WARN ][plugins.reporting.config] Found 'server.host: "0.0.0.0"' in Kibana configuration. Reporting is not able to use this as the Kibana server hostname. To enable PNG/PDF Reporting to work, 'xpack.reporting.kibanaServer.hostname: localhost' is automatically set in the configuration. You can prevent this message by adding 'xpack.reporting.kibanaServer.hostname: localhost' in kibana.yml.
[2023-01-06T01:37:05.393+00:00][INFO ][plugins.ruleRegistry] Installing common resources shared between all indices
[2023-01-06T01:37:05.444+00:00][INFO ][plugins.cloudSecurityPosture] Registered task successfully [Task: cloud_security_posture-stats_task]
[2023-01-06T01:37:07.438+00:00][INFO ][plugins.screenshotting.config] Chromium sandbox provides an additional layer of protection, and is supported for Linux Ubuntu 20.04 OS. Automatically enabling Chromium sandbox.
[2023-01-06T01:37:08.531+00:00][ERROR][elasticsearch-service] Unable to retrieve version information from Elasticsearch nodes. connect ECONNREFUSED 10.233.6.42:9200
[2023-01-06T01:37:11.376+00:00][INFO ][plugins.screenshotting.chromium] Browser executable: /usr/share/kibana/x-pack/plugins/screenshotting/chromium/headless_shell-linux_x64/headless_shell
[2023-01-06T01:40:27.045+00:00][ERROR][elasticsearch-service] Unable to retrieve version information from Elasticsearch nodes. Request timed out
[2023-01-06T01:40:30.573+00:00][ERROR][elasticsearch-service] Unable to retrieve version information from Elasticsearch nodes. connect ECONNREFUSED 10.233.6.42:9200
^C
Actually it's possible to set the password to a well known value by creating the
{clusterName}-es-elastic-user
Secret before creating the Elasticsearch resource:$ kubectl create secret generic testing-es-elastic-user --from-literal=elastic=foobar secret/testing-es-elastic-user created $ cat <<'EOFTEST' | kubectl apply -f - apiVersion: elasticsearch.k8s.elastic.co/v1alpha1 kind: Elasticsearch metadata: name: testing spec: version: 7.1.0 nodes: - nodeCount: 1 EOFTEST elasticsearch.elasticsearch.k8s.elastic.co/testing configured $ # set up any forwarding you need after the ES pod is done initializing, e.g in another terminal: $ kubectl port-forward service/testing-es 9200:9200 $ curl -k -u elastic:foobar https://localhost:9200 { "name" : "testing-es-5ps8sl8sfn", "cluster_name" : "testing", ... "tagline" : "You Know, for Search" }
Thanks to @agup006 for pointing this one out to me.
I would file this under "workaround" for now, and not an officially supported feature.
But what will happen when the the cluster is already present and we want to change the elastic superuser password. we can't recreate elasticsearch cluster again
Proposal
Use case. Why is this important?
In many environments, being able to set the password to something assumed is important. For example in a training course where we provide instructions, it is cumbersome to have unique passwords for each student's install and have to make them find out what the password is from a secret and then populate it in configuration files like for filebeat, etc.
I've tried work arounds with this. For example the
bin/elasticsearch-setup-passwords
command does not work from a cluster deployed by the operator which leads me to believe it was already changed. I then try to work around this by changing it with the API:However the above does not work because apparently the built-in users are not found and/or allowed to be changed with the API. Below was the error returned from the API:
Validation Failed: 1: user must exist in order to change password;