Using env-injector with aad-pod-identity allows getting all secrets

[maboehm]

Describe the bug
I feel like this is a consequence of the fundamental design of the env-injector, but I'd like to discuss the consequences.

When using the env-injector with customAuth, I have to add a aadpodidbinding label to the pod, so that the Injector can connect to Key Vault using the credentials of the pod. Consequently, this means, that later, once inside the container, i can simply connect to the Key Vault directly and get any secret:

curl 'http://169.254.169.254/metadata/identity/oauth2/token?api-version=2018-02-01&resource=https%3A%2F%2Fvault.azure.net' -H Metadata:true
curl https://<YOUR-KEY-VAULT-URL>/secrets/<secret-name>?api-version=2016-10-01 -H "Authorization: Bearer <ACCESS TOKEN>"

Maybe there is another way to configure the Injector that I'm missing? The way it currently is, I am not gaining much in terms of security.

Steps to Reproduce:

# injector-val.yml

customAuth:
  enabled: true
  autoInject:
    enabled: true
    podIdentitySelector: <pod-selector>

# deployment.yml

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: test
spec:
  replicas: 1
  selector:
    matchLabels:
      app: test
  template:
    metadata:
      labels:
        app: test
        aadpodidbinding: <pod-selector>
    spec:
      containers:
        - env:
            - name: password
              value: password@azurekeyvault
            - name: ENV_INJECTOR_LOG_LEVEL
              value: debug
          image: <my-image>
          imagePullPolicy: Always
          name: test

Expected behavior
I was hoping to limit the access to Key Vault secrets in case of a malicious take-over. To me, it seems like using the env-injector that is not the case.

[torresdal]

See your point, but not really something we can control from the injector. The injecter basically gets handed some credentials to use to access azure key vault. What you are referring too is basically how MS implementation of pod identity works.

It is possible to pass the injector a specific service principal, without using pod identity, but not convenient. On this topic, MS is also adding native support for managed identities in AKS, currently in preview: https://docs.microsoft.com/en-us/azure/aks/use-managed-identity

None of this will help much in what you are aiming for.

The last thing is how authorization works in AKV - not letting you limit access to individual secrets.

This is why we typically create many different key vaults. Each with its own purpose- either for an application or dedicated to a Kubernetes cluster.

[torresdal]

We are of course open for any suggestions you might have, that would make the env injector better. But on this topic I personally can’t see what we could do differently to improve the situation.

[torresdal]

Closing for now.