I’d like to work on a new feature improvement which improves the the reload function of the Kubernetes Controller by broadening the scope for where the controller current checks for secrets. For Example, a Minio deployment requires a few secrets and they are mounted as projected volumes, so even with the

<http://secrets.infisical.com/auto-reload|secrets.infisical.com/auto-reload>: "true"

the current controller does not look for the secret there, as its only checking

volume.Secret.SecretName

It would be great if the controller recursively checks an entire manifest to see if the

managedKubeSecretReferences

is present anywhere in the file where the

<http://secrets.infisical.com/auto-reload|secrets.infisical.com/auto-reload>: "true"

is set. My only concern would be the overhead of recessively checking a manifest if the manifest is extremely large. While reviewing different solutions this was an output from my conversation with Cursor: The implementation would likely have moderate impact because: 1. Limited Scope: ◦ Only runs on workloads with the auto-reload: “true” annotation ◦ Only processes resources in the same namespace as the secret 2. Reconciliation Timing: ◦ Default reconciliation is relatively infrequent (1 minute+) ◦ Processing overhead is unlikely to be continuous 3. Kubernetes Context: ◦ Kubernetes manifests, while they can be large, aren’t typically gigabytes ◦ Most workloads have reasonably sized manifests (<100KB) Would love any thoughts or feedback. Happy to work on the PR for this, if you think this feature would be helpful