Read the password from file and ensure better compatibility with the elastic operator

New Features Ideas
1

:bulb: Read password from file

Read the password from file and ensure compatibility with the elastic operator.

The docs from elastic points to rotation of passwords by deleting a secret: k8s-rotate-credentials
This can be shown in the operator log:

{
  "log.level":"info","@timestamp":"2024-06-20T05:46:33.045Z",
  "log.logger":"elasticsearch-controller",
  "message":"Updating resource",
  "service.version":"2.10.0+59c1e727",
  "service.type":"eck",
  "ecs.version":"1.4.0",
  "iteration":"5",
  "namespace":"namespace",
  "es_name":"cluster",
  "kind":"Secret",
  "namespace":"namespace",  # it is really defined twice.
  "name":"cluster-es-internal-users"
}

This will update any filemount secrets, but does not update environment referenced secrets.

  • This will update
      volumes:
  - name: elastic-internal-probe-user
    secret:
      defaultMode: 420
      items:
      - key: elastic-internal-probe
        path: elastic-internal-probe
      - key: elastic-internal-pre-stop
        path: elastic-internal-pre-stop
      optional: false
      secretName: cluster-es-internal-users
  • This wil not update and is one time only.
      - env:
    - name: INTERNAL_USR_PASS
      valueFrom:
        secretKeyRef:
          key: elastic-internal
          name: cluster-es-internal-users

In the example given kind-cluster/ror/es.yml the environment variable is used inside the readonlyrest configuration. This will ensure a one time only working version.

We had a little misconfiguration where the pre-stop user was rotated every few hours and after that the password did not match. Hence this request.

A option to read the passwords from file:

  • /mnt/elastic-internal/pod-mounted-users/elastic-internal-pre-stop
  • /mnt/elastic-internal/pod-mounted-users/elastic-internal-probe

:eyes: Example

There are multiple ways to implement this.

  1. basic with no ‘:’ requires a extra file entry

    readonlyrest:
  access_control_rules:
  - name: "::PROBE::"
    auth_key: username  # no colon
    auth_key_filename: /mnt/elastic-internal/pod-mounted-users/elastic-internal-probe

  2. more intrusive and redesign auth_key and make it more generic

    readonlyrest:
  access_control_rules:
  - name: "::BASIC::"
    auth_key:
      type: basic  # default basic can be removed
      username: elastic-internal-probe
      password: password
  - name: "::PROBE::"
    auth_key:
      type: basic  # default basic can be removed
      username: elastic-internal-probe
      filename: /mnt/elastic-internal/pod-mounted-users/elastic-internal-probe
  - name: "::TEST::"
    auth_key:
      type: unix
      key: test:$6$rounds=65535$d07dnv4N$QeErsDT9Mz.ZoEPXW3dwQGL7tzwRz.eOrTBepIwfGEwdUAYSy/NirGoOaNyPx8lqiR6DYRSsDzVvVbhP4Y9wf0 #test:test
      # or username, password

  3. Just detect that elasticsearch is managed with an operator and read those 2 in without defining them in the readonlyrest configuration.

    "@timestamp":"2024-06-14T06:16:16.547Z", "log.level": "INFO", "message":"[ROR] Detected elstic operator" }
"@timestamp":"2024-06-14T06:16:16.547Z", "log.level": "WARN", "message":"[ROR] Importing user elastic-internal-probe" }

:rocket: Let’s do this?

  • 1
  • 2
  • 3
  • 4
  • 5
0 voters
2

Hi @BobVanB

This is a great idea.

In ROR we have static variables and dynamic variables.

So, it seems that there is no need to change the auth rules, but we could introduce a new variable. it could look like this in ROR ACL:

readonlyrest:
  access_control_rules:
  - name: "::BASIC::"
    auth_key: "elastic-internal-probe:password"
  - name: "::PROBE::"
    auth_key: "elastic-internal-probe:@{file:/mnt/elastic-internal/pod-mounted-users/elastic-internal-probe}"

WDYT?

3

We should obviously check if accessing files from the local filesystem (outside of ES dir) will be possible (without introducing additional permissions) … but it’s a rather technical problem we have to think about.

1 Like
4

This solutions seems simple, i like it.

auth_key: "elastic-internal-probe:@{file:/mnt/elastic-internal/pod-mounted-users/elastic-internal-probe}

And i think its enough to ensure it throws an error if it can’t read the file.