[BUG] Auto mode fails to detect secret changes when volume name differs from secret name

[Paul-Mandell]

Describe the bug

Reloader's auto mode (reloader.stakater.com/auto: "true") fails to detect and trigger pod restarts when secrets are updated if the volume name in the deployment differs from the secret name. This causes silent failures in production environments where secrets rotate but pods continue using stale credentials.

To Reproduce

Steps to reproduce the behavior:

1. Create a secret named db-credentials:

apiVersion: v1
kind: Secret
metadata:
  name: db-credentials
type: Opaque
data:
  DATABASE_PASSWORD: <base64-encoded-value>

2. Create a deployment that mounts this secret with a different volume name:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-application
  annotations:
    reloader.stakater.com/auto: "true"
spec:
  template:
    spec:
      containers:
      - name: app
        volumeMounts:
        - mountPath: "/etc/secrets/db-credentials-optional"
          name: "db-credentials-optional"
          readOnly: true
      volumes:
      - name: "db-credentials-optional"
        secret:
          secretName: "db-credentials"
          items:
          - key: "DATABASE_PASSWORD"
            path: "DATABASE_PASSWORD"

3. Update the secret db-credentials with new data
4. Observe that Reloader does NOT trigger a pod restart
5. Compare with a ConfigMap that has matching names - those DO trigger restarts

Expected behavior

When the secret db-credentials is updated, Reloader should:

1. Detect the secret change
2. Parse the deployment's volumes section
3. Extract the actual secretName field from the volume definition
4. Match it to the changed secret
5. Trigger a pod restart

Currently, Reloader only matches on volume name (db-credentials-optional) and fails to find the actual secret name (db-credentials), so no restart occurs.

Screenshots

Not applicable - this is a logic/matching issue in how Reloader parses volume definitions.

Environment

• Operator Version: v2.2.8
• Kubernetes/OpenShift Version: Affects all Kubernetes versions

Additional context

This is a critical issue for production environments with automated credential rotation. When secrets rotate (database credentials, cloud provider keys), pods keep using expired credentials, causing applications to fail connecting to services while pods appear healthy.

Volume names often differ from secret names for organizational clarity (e.g., -optional, -required suffixes), multiple mounts of the same secret, or team naming conventions. ConfigMaps work because they're typically referenced with matching names via configMapRef, while Secrets use volume mounts where names can differ.

Current workaround requires explicitly listing secrets by name, which defeats the purpose of auto mode:

metadata:
  annotations:
    secret.reloader.stakater.com/reload: "db-credentials"

Proposed fix: Reloader should parse volumes[].secret.secretName instead of just matching on volumes[].name when checking if a deployment uses a secret. This also affects projected volumes combining multiple secrets.