OIDC makes a lot of sense for cloud services because edge functions can exchange a runtime identity for short-lived credentials instead of storing permanent AWS access keys in environment variables. The complication is that many SaaS providers, such as OpenAI or Resend, do not support OIDC or token exchange, so their API keys still have to be stored somewhere. The usual suggestion is to use OIDC for internal cloud infrastructure and a secrets manager for external services. How are you handling this split in production? Does the hybrid setup create much operational overhead, or is it simply the normal approach?
3 Answers
We keep the external credentials in Infisical and let the deployment pipeline authenticate to it through OIDC. Once the integration is configured, it runs with very little ongoing supervision.
We use OIDC wherever the provider supports it, then store the remaining application credentials in AWS Secrets Manager or Systems Manager Parameter Store. The application retrieves those values at runtime rather than putting them in the code or deployment configuration.
So the hybrid approach really is the standard once you account for services that only offer static API keys.
A hybrid setup is completely normal. Use OIDC for services that support it and a secrets manager for third-party API keys. As long as the keys stay out of the source code, have the narrowest permissions possible, and can be rotated easily, there usually is not much more complexity worth worrying about.
That sounds reasonable. Does maintaining the Infisical integration add much work to the pipeline, or is it mostly hands-off after the initial setup?