Improve config/recipes/elastic-agent/fleet-kubernetes-integration-nonroot.yaml with drop capabilities#8811
Conversation
…root.yaml with drop capabilities
🎉 Snyk checks have passed. No issues have been found so far.✅ security/snyk check is complete. No issues have been found. (View Details) ✅ license/snyk check is complete. No issues have been found. (View Details) |
| spec: | ||
| serviceAccountName: fleet-server | ||
| automountServiceAccountToken: true | ||
| ## Uncomment the following lines to run fleet-server with restricted privileges and drop capabilities. |
There was a problem hiding this comment.
2 things I'm not sure:
- Should it be the default in this recipe? (Said differently, should we remove the
#?) - Do we want to apply the same changes to the Agents below? I think we don't as it could break some packages which may require some capabilities to run correctly?
There was a problem hiding this comment.
For a managed elastic-agent, the important bits are:
- have the CONFIG_PATH and the STATE_PATH being writable and persisted across restarts (hence the 2 env vars below)
- the
-c /etc/agent/elastic-agent.ymlwhich will cause the config file to be copied in the state path and used allowing for some initial config injection from secrets/config maps.
The securityContext part is optional and depends on how locked down the user wants the agent containers to be and it's more a case-by-case choice so I would leave that commented and let the user be stricter if he needs to be.
The changes I mentioned above need to be replicated to the elastic-agent Agent as well.
|
I'm closing this PR since what we are trying to solve here is not related to whether the container is running as |
rhr323
added
the
exclude-from-release-notes
4 participants
This PR improves
config/recipes/elastic-agent/fleet-kubernetes-integration-nonroot.yamlto explain how to run Fleet server with dropped capabilities and ro file system.(I think ECK should ideally do that by default as it is already the case for Elasticsearch and Kibana)