Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[bitnami/elasticsearch] Modify elasticsearch.yaml - permission denied #27532

Closed
Harrys-git opened this issue Jun 25, 2024 · 6 comments
Closed
Assignees
Labels
elasticsearch solved stale 15 days without activity tech-issues The user has a technical issue about an application

Comments

@Harrys-git
Copy link
Contributor

Name and Version

bitnami/elasticsearch 21.1.0

What architecture are you using?

None

What steps will reproduce the bug?

I am trying to helm install elasticsearch onto an openshift cluster with no rights to run containers as root.

Are you using any custom parameters or values?

Whilst setting the below config in the helm chart I run into permission issues.

config:
  xpack.security.http:
    ssl:
      enabled: "true"
      key: <path/to/custom-key>
      certificate: <path/to/custom-key>
      certificate_authorities: <path/to/custom-key>

What is the expected behavior?

I expect the chart to modify the yaml found at /opt/bitnami/elasticsearch/config/elasticsearch.yml with my provided http config.

What do you see instead?

Error:

fatal exception while booting elasticsearch java.lang.IllegalStateException: Unable to access 'path.data' (/opt/bitnami/elasticsearch/data)
Caused by: java.nio.file.FileSystemException: /opt/bitnami/elasticsearch/data: Read-Only file system.

After reading the README.md of the bitnami/elasticsearch repo I see this

Adjust permissions of persistent volume mountpoint
As the image run as non-root by default, it is necessary to adjust the ownership of the persistent volume so that the container can write data into it.

By default, the chart is configured to use Kubernetes Security Context to automatically change the ownership of the volume. However, this feature does not work in all Kubernetes distributions. As an alternative, this chart supports using an initContainer to change the ownership of the volume before mounting it in the final destination.

You can enable this initContainer by setting volumePermissions.enabled to true.

So I tried to set the initContainer up but I am unable to "runAsUser: 0" in my environment.

How do I change the elasticsearch.yaml if its read only?
I have tried, init containers, mounting the config myself and other ways of doing it myself but its not working properly.

Additional information

No response

@Harrys-git Harrys-git added the tech-issues The user has a technical issue about an application label Jun 25, 2024
@github-actions github-actions bot added the triage Triage is needed label Jun 25, 2024
@github-actions github-actions bot removed the triage Triage is needed label Jun 26, 2024
@github-actions github-actions bot assigned juan131 and unassigned javsalgar Jun 26, 2024
@juan131
Copy link
Contributor

juan131 commented Jun 26, 2024

Hi @Harrys-git

Could you please try to install the chart using the suggestion below (undoing the security improvement changes)?

Please let us know if that's the case so we can give you further suggestions to make the chart compatible with your environment.

@Harrys-git
Copy link
Contributor Author

Harrys-git commented Jun 26, 2024

I attempted the following:
Added the "config" block back to helm chart

  1. runAsGroup: 0 = Failed to start pods due to security policies
  2. global.compatibility.openshift.adaptSecurityContext: disabled = Failed to start pods due to security policies
  3. readOnlyRootFilesystem: false = Unable to access 'path.data' (/opt/bitnami/elasticsearch/data) Caused by AccessDnied Exception. /opt/bitnami/elasticsearch/data (this was on all elastic nodes)

@Harrys-git
Copy link
Contributor Author

The only way around this was to run an initScript that uses sed to replace the lines necessary. The initScript doesn't work properly without creating an emptyDir like explained in this ticket #24473.
Code is as follows:

extraVolumeMounts:
  - name: empty-dir
    mountPath: /bitnami/elasticsearch
    subPath: app-volume-dir

@juan131
Copy link
Contributor

juan131 commented Jun 28, 2024

Hi @Harrys-git

The default configuration file for Elasticsearch (when no custom configuration is provided) looks like this:

http:
  port: "9200"
path:
  data: /bitnami/elasticsearch/data
transport:
  port: "9300"
network:
  host: 10.244.0.6
  publish_host: 10.244.0.6
  bind_host: 0.0.0.0
cluster:
  name: elastic
node:
  name: elasticsearch-master-0
discovery:
  type: single-node
xpack.security.http:
  ssl:
    enabled: false
xpack:
  security:
    enabled: "false"
  ml:
    enabled: "false"

As you can see, the "data" directory is /bitnami/elasticsearch/data where you shouldn't find permissions issues. The problem is that you're overriding this configuration file.

This is sth you can avoid using the extraConfig parameter (which extends the default configuration) instead of the config parameter (which overrides it). Alternatively, you can keep using config as you're doing now, but pleas ensure you add the block below:

path:
  data: /bitnami/elasticsearch/data

Copy link

This Issue has been automatically marked as "stale" because it has not had recent activity (for 15 days). It will be closed if no further activity occurs. Thanks for the feedback.

@github-actions github-actions bot added the stale 15 days without activity label Jul 14, 2024
Copy link

Due to the lack of activity in the last 5 days since it was marked as "stale", we proceed to close this Issue. Do not hesitate to reopen it later if necessary.

@bitnami-bot bitnami-bot closed this as not planned Won't fix, can't repro, duplicate, stale Jul 20, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
elasticsearch solved stale 15 days without activity tech-issues The user has a technical issue about an application
Projects
None yet
Development

No branches or pull requests

4 participants