[BUG] AKS expose secrets in logs in default configuration

[nixx]

Describe the bug The behaviour is described in https://github.com/Azure/AKS/issues/1389

The issue describes a workaround, but the default configuration is still counter intuitive. We experienced secrets in logs with the default setup.

To Reproduce Deploy a pod with the following configuration (from https://kubernetes.io/docs/tasks/inject-data-application/distribute-credentials-secure/):

apiVersion: v1
kind: Pod
metadata:
  name: env-single-secret
spec:
  containers:
  - name: envars-test-container
    image: nginx
    env:
    - name: SECRET_USERNAME
      valueFrom:
        secretKeyRef:
          name: backend-user
          key: backend-username

Expected behavior SECRET_USERNAME is not shown in logs

Environment (please complete the following information):

Additional context The standard behaviour is in counterintuitive with Kubernetes documentation in mind. See https://kubernetes.io/docs/tasks/inject-data-application/distribute-credentials-secure/ . This makes password leakage highly probable.

[blurpy]

Since default log configuration exposes secrets, should there be a CVE assigned to this?

[PixelRobots]

Avoiding the use of secrets in environment variables is a recommended practice in Azure and many other cloud platforms. This is because environment variables can be accessed by any process running in the same environment, potentially leading to unintended exposure of sensitive information. You will notice in the Kubernetes link you provided that the first example is to mount the secrets as a volume in the pods.

It is recommended to use Azure Key Vault for storing and managing secret and then using the Azure Key Vault Secrets Store CSI driver to inject the secrets into the pod.

Adding the azure monitor team for feedback on the default.

[nixx]

I´m fully aware of recommended practice in Azure. But AKS is Kubernetes, and you simply can´t redefine Kubernetes security model.

You will notice in the Kubernetes link you provided that the first example is to mount the secrets as a volume in the pods.

I did notice. Being the first is irrelevant. Both methods are described, and there is no documentation of one being better or worse than the other. There are a lot of valid use cases to put configuration and secrets in environment variables.

A commonly used application pattern is https://12factor.net/config , which mandates configuration in the environment. Microsoft even refers to that pattern in https://learn.microsoft.com/en-us/dotnet/architecture/modernize-with-azure-containers/modernize-existing-apps-to-cloud-optimized/what-about-cloud-native-applications#cloud-native-applications-details

I quote:

The Twelve-Factor App (a collection of patterns that are closely related to microservices approaches) is also considered a requirement for cloud-native application architectures.

I would argue that configuration in environment variables is a valid and much used pattern. Providing sensible secure defaults for that pattern is expected.

[floriankoch]

See https://github.com/Azure/AKS/issues/3812