secrets-store-csi-driver | Secrets Store CSI driver for Kubernetes secrets | Storage library

After doing some tests, it seems that the process that I was following was correct. Most probably, I was using principalId instead of clientId in role assignment for the AKS managed identity.

Key points for someone else that is facing similar issues:

1. Check what the managed identity created automatically by AKS is. Check for the clientId; e.g.,

i was able to solve this issue by updating the entrypoint.sh to export the secrets to env variables. Something like this:

There are many possible motivations why you may want to use an abstraction (such as the CSI driver or sidecar injector) over a native integration:

• Portability - If you're multi-cloud or multi-target, you may have multiple secret management solutions. Or you might have a different secret manager target for local development versus production. Projecting secrets onto a virtual filesystem or into environment variables provides a "least common denominator" approach that decouples the application from its secrets management provider.

• Local development - Similar to the previous point on portability, it's common to have "fake" or fakeish data for local development. For local dev, secrets might all be fake and not need to connect to a real secret manager. Moving to an abstraction avoids error-prone spaghetti code like:

The comment on the answer you linked was incorrect. I've left a note to explain the confusion. What you have is fine, if possibly over-built :) You're not actually gaining any security vs. just using Kubernetes Secrets directly but if you prefer the workflow around AKV then this looks fine. You might want to look at externalsecrets rather than this weird side feature of the CSI stuff? The CSI driver is more for exposing stuff as files rather than external->Secret->envvar.

The CSI secret store driver is a container storage interface driver - it can only mount to files.

For postgres specifically, you can use docker secrets environment variables to point to the path you're mounting the secret in and it will read it from the file instead. This works via appending _FILE to the variable name.

Per that document: Currently, this is only supported for POSTGRES_INITDB_ARGS, POSTGRES_PASSWORD, POSTGRES_USER, and POSTGRES_DB.

Looks it is related to the default network plugin that AKS picks for you if you don't specify "Advanced" for network options: kubenet.

This integration can be done with kubenet outlined here:

https://azure.github.io/aad-pod-identity/docs/configure/aad_pod_identity_on_kubenet/

If you are creating a new cluster, enable Advanced networking or add the --network-plugin azure flag and parameter.

According to the official docs:

This command installs a chart archive.

The install argument must be a chart reference, a path to a packaged chart, a path to an unpacked chart directory or a URL.

To override values in a chart, use either the –values flag and pass in a file or use the –set flag and pass configuration from the command line. To force string values in –set, use –set-string instead. In case a value is large and therefore you want not to use neither –values nor –set, use –set-file to read the single large value from file.

CHART REFERENCES

A chart reference is a convenient way of reference a chart in a chart repository.

When you use a chart reference with a repo prefix (‘stable/mariadb’), Helm will look in the local configuration for a chart repository named ‘stable’, and will then look for a chart in that repository whose name is ‘mariadb’. It will install the latest version of that chart unless you also supply a version number with the ‘–version’ flag.

To see the list of chart repositories, use ‘helm repo list’. To search for charts in a repository, use ‘helm search’.