Check and move all sensitive data in Kubernetes Secrets

[asatt]

Is your feature request related to a problem? Please describe

We have a requirement from the Security team to save all types of sensitive data in Kubernetes Secrets.
It needs to use the future External Secret Operator to manage the Secret and fill it from trusted and encrypted storage (like Vault).

Moreover, they have a wider request:

• All types of sensitive data should be stored only in Kubernetes Secrets
• Data from Kubernetes Secret shouldn't be mounted as an ENV variable
• Kubernetes Secrets can be used like the following:
  • Referer in the Custom Resource (CR) and read data from the Secret in the program controller
  • Discover and read data from Secrets in the program controller
  • Mount as a file in a container rootfs

Types of sensitive data:

• Credentials
• Tokens
• Private parts of certificates (all types of certificates can be saved in Secrets)

Describe the solution you'd like

Need to:

• Check all components included in Monitoring
• Find which credentials are being used and how using in these components
• Fix if somewhere data from Secret mount as ENV

Describe alternatives you've considered

No response

Additional information

No response

[NikolaiKuziaevQubership]

Component name	Secrets with violations	Solution per component
Operator (logging-service-operator)	GRAYLOG_USERNAME GRAYLOG_PASSWORD ELASTICSEARCH_HOST	Changes are feasible: the code lives in this repository, so credential handling can be moved from os.Getenv to reading mounted secret files
Integration tests	GRAYLOG_USER GRAYLOG_PASS VM_USER SSH_KEY VL_TOKEN VL_USER VL_PASSWORD	Changes are feasible: the container image and the code used to build it are fully maintained in the qubership-logging-operator repository
Graylog (graylog / graylog container)	GRAYLOG_ELASTICSEARCH_HOSTS GRAYLOG_USERNAME GRAYLOG_PASSWORD AWS_ACCESS_KEY_ID AWS_SECRET_ACCESS_KEY	Per Graylog Docker docs, any setting from graylog.conf can be passed as GRAYLOG_<NAME_IN_UPPER_CASE>__FILE pointing at a mounted secret file A separate table with mapping is presented below. AWS_ACCESS_KEY_ID/AWS_SECRET_ACCESS_KEY are not graylog.conf keys — no GRAYLOG_*__FILE mapping Archiving plugin reads those only from ENV ArchivingModule.java#L44 plugin code change is required to support files Will not change the AWS_* parameters, as there is little value in modifying a seldom‑used plugin.
Fluent Bit (logging-fluentbit) and Fluent Bit Aggregator (logging-fluentbit-aggregator)	LOKI_USERNAME LOKI_PASSWORD LOKI_TOKEN HTTP_USERNAME HTTP_PASSWORD HTTP_TOKEN OTEL_USERNAME OTEL_PASSWORD OTEL_TOKEN	Gap Per upstream docs, Loki output parameters that carry secrets are effectively string-only (Fluent Bit 4.2 — Loki output) Same for HTTP output (Fluent Bit 4.2 — HTTP output) Same for OpenTelemetry output (Fluent Bit 4.2 — OpenTelemetry output) 1) Prepare small config fragments that contain sensitive values 2) Mount them into the container 3) Merge those fragments into the main config using @INCLUDE classic config — include file fluentbit does not plan any changes related to the transition from env variables, proof Will put the whole Fluent config into one Secret to keep management simpler Do this by directly calling the configuration file. Similar to FluentD.
FluentD (logging-fluentd)	LOKI_USERNAME LOKI_PASSWORD HTTP_USERNAME HTTP_PASSWORD HTTP_TOKEN	Sensitive values can be injected in Ruby: from a mounted file with #{File.read('/path/to/token').strip} or from the environment with #{ENV['HTTP_TOKEN']}

Mapping table for Graylog:

graylog.conf	Helm variable	File-based env
elasticsearch_hosts	GRAYLOG_ELASTICSEARCH_HOSTS	GRAYLOG_ELASTICSEARCH_HOSTS__FILE
root_username	GRAYLOG_USERNAME	GRAYLOG_ROOT_USERNAME__FILE
root_password_sha2	GRAYLOG_PASSWORD	GRAYLOG_ROOT_PASSWORD_SHA2__FILE (value must be SHA-256 hash)