Hi, From what i understand from the universal auth /w periodic token documentation, the clientID and clientSecret only needs to be used once during initial authentication between the workload and infisical. Subsequent api-calls made to inifiscal will use a generated access token, which will be automatically refreshed to avoid expiration. When I've tested this from a k8s cluster with an externalSecretStore, the cluster keeps using the clientID and clientSecret, eventually exhausting clientSecret usage limit (I've used everything between 1 and 10 as the usage limit). The usage limit on the access token is set to 0. So i don't understand why i'm seeing this behaviour. My expectation would be that the cluster would just authenticate once with the clientID and clientSecret, then switch over to using the access token. If anyone could clarify if what i'm seeing is expected behaviour and if not, potential root causes. Summary of the authentication setup: 1. Project-scoped machine identity configured with universal auth. a. Universal auth configuration: i. Access token period: 3600s ii. Lockout: Disabled iii. Access token max number of uses: Not set iv. Client secret ttl: 0 v. Client secret max number of uses: 10 b. Project roles: Viewer c. Additional privilege policy: read access to Secrets for specific environment slug. Documentation reference: infisical.com/docs/…/universal-auth#… Thanks in advance,

Hi Tobias, thanks for the detailed writeup! What you're seeing is expected. On Universal Auth, the External Secrets Operator logs in fresh on every reconcile rather than reusing one token, and Infisical's "Client Secret Max Number of Uses" counts each of those logins. So with the limit set to 1-10, it gets used up almost immediately. The cleanest fix is to switch your ESO SecretStore from Universal Auth to Kubernetes auth. Your pods authenticate using their service account (Infisical validates it via the Kubernetes TokenReview API), so there's no client secret in the flow at all and nothing to exhaust. You can stay on ESO and just swap the auth method. If you'd rather stick with Universal Auth, the quick fix is to leave the client secret's "Max Number of Uses" unset (unlimited) and rely on the access token TTL and period for your guardrails instead, since those aren't consumed by logins. Also if you're ever open to it, we also have our own native Kubernetes operator that caches and reuses the token across all your secrets so it sidesteps this entirely. Let me know if this clears things up! Thanks

Hi Jake, thanks for the reply. • Using Kubernetes Auth. ◦ We used this while testing infisical on-prem, which worked flawlessly. However, for production use, we're looking to move into a cloud-hosted instance of Infisical. However, as setting up kubernetes auth via a Network gateway setup is an Enterprise-tier feature (we're not an enterprise company and cannot justify going for that license tier), this isn't really an option for us.

Hey Tobias, sorry for the late response here. The K8s operator itself should work! It only ever calls out to Infisical to pull secrets, it never needs Infisical to reach back in so there isn't a gateway needed there. You can keep using it, just point it at Universal Auth instead of Kubernetes Auth and set the client secret's "Max Number of Uses" to unlimited so it won't run out. This'll be all outbound. Out of curiosity, which cloud are you on? If it's AWS, GCP, or Azure we can use cloud native identity to authenticate as well!