Description of problem:

When installing LokiStack according to Installing Loki Operator using the OpenShift Container Platform CLI a secret needs to be created that contains information on how to access the respective object storage (see Loki object storage

So while it's generally OK to put such sensitive data into a kubernetes secret resource, it's not expected that those information are copied to a ConfigMap and thus may become accessible to users unexpected (we need to understand that access to secret and ConfigMap can be restricted on per user basis.

Below is an example of the config.yaml content in ConfigMap called logging-loki-config

---
auth_enabled: true
chunk_store_config:
  chunk_cache_config:
    embedded_cache:
      enabled: true
      max_size_mb: 500
common:
  storage:
    s3:
      s3: s3.us-east-2.amazonaws.com
      bucketnames: loki
      region: us-east-2
      access_key_id: <removed>
      secret_access_key: <removed>
      s3forcepathstyle: true
  compactor_grpc_address: logging-loki-compactor-grpc.openshift-logging.svc.cluster.local:9095

This behavior is considered a security violation as customers are not informed that the sensitive data will be copied to the ConfigMap and again we are leaking sensitive data originally created in secret in a ConfigMap.

It's therefore expected that this is being addressed and LokiStack becomes able to read sensitive information for it's storage configuration from the previously created secret via respective reference in the config.yaml or somehow different.

Version-Release number of selected component (if applicable):

OpenShift Container Platform 4 - Cluster Logging 5.8.0

How reproducible:

Always

Steps to Reproduce:

1. Deploy LokiStack according to Installing Loki Operator using the OpenShift Container Platform CLI
2. Check the content of ConfigMap called logging-loki-config

Actual results:

ConfigMap called logging-loki-config is exposing sensitive information which are expected to resist in a secret resource.

---
auth_enabled: true
chunk_store_config:
  chunk_cache_config:
    embedded_cache:
      enabled: true
      max_size_mb: 500
common:
  storage:
    s3:
      s3: s3.us-east-2.amazonaws.com
      bucketnames: loki
      region: us-east-2
      access_key_id: <removed>
      secret_access_key: <removed>
      s3forcepathstyle: true
  compactor_grpc_address: logging-loki-compactor-grpc.openshift-logging.svc.cluster.local:9095

Expected results:

No information from secret resources leaked in ConfigMap and instead referring to the required secret and consuming it accordingly.

Additional info: