Replies: 1 comment 3 replies
-
Hey @rawkode We have already worked with external secret operator to built an infisical provider that uses the universal auth quite fine. We are moving away from service token because more customers wants to do multiple things with token and service token was never good for that due to permission and programmatic integration inside the app too. We haven't depreciated the service token yet and brainstorming more on this one for easiness on universal token usage. Thank you for reaching out to express your concern over universal auth we will keep this consider in our future discussion too. |
Beta Was this translation helpful? Give feedback.
3 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Feature description
Some existing tools will be unable to authenticate against the Infisical API using the current list of supported authentication methods, of which the "generic" solutions are Universal Auth and Kubernetes Auth.
Unfortunately both of those methods require an interaction step, a login to retrieve a token, then use of that token in subsequent API calls.
This would make it impossible to use tools like the External Secrets Operator.
The External Secrets Operator WebHook provider could authenticate with the Infisical API using a Service Token but cannot currently use "Universal Auth".
I imagine there are other similar scenarios where existing solutions would work with bearer token authentication but cannot easily use "Universal Auth".
Why would it be useful?
Why would this feature be useful for Infisical users?
The External Secrets Operator can transform Infisical Secrets into many useful different forms for Kubernetes. Using the External Secrets Operator would address issue #1072, for example.
It would be ideal to be able to create a bearer token for a Machine Identity and have that token automatically populate an Infisical Secret. The Infisical Kubernetes operator could then export that secret into a Kubernetes secret, which in turn could be used by the External Secrets Operator to authenticate against the Infisical API making it possible.
The ability to query multiple secretes in a single API call would also be very helpful in this scenario, making it very easy to create kubernetes basic-auth secrets and more.
Beta Was this translation helpful? Give feedback.
All reactions