Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support OIDC for Provider connection #522

Open
1 task done
fproulx-boostsecurity opened this issue Mar 10, 2023 · 3 comments
Open
1 task done

Support OIDC for Provider connection #522

fproulx-boostsecurity opened this issue Mar 10, 2023 · 3 comments
Labels
🌱 feature New feature or request

Comments

@fproulx-boostsecurity
Copy link

Checklist

Describe the problem you'd like to have solved

Similar to how AWS, GCP, Azure terraform providers support OIDC to authenticate from GitHub Actions for instance (https://docs.github.com/en/actions/deployment/security-hardening-your-deployments/configuring-openid-connect-in-amazon-web-services) it would be really nice for Auth0 provider to do that too.

That would allow to remove any long term secrets to connect to Auth0 provider and make IaC more secure.

Describe the ideal solution

Provider not only support OAuth client secret, but a mechanism to get ephemeral access based on OIDC claims trusting GitHub Actions

Alternatives and current workarounds

No response

Additional context

No response

@fproulx-boostsecurity fproulx-boostsecurity added the 🌱 feature New feature or request label Mar 10, 2023
@sergiught
Copy link
Contributor

Hey @fproulx-boostsecurity 👋🏻

Thanks for raising this with us, it's a great suggestion! 🥳 Additionally we could expand further and include even more ways of authenticating, even leveraging the Auth0 CLI.

To set some realistic expectations, at the moment our biggest focus is to get this provider to a stable v1. So tackling something like additional authentication options will most likely come afterwards.

We'll keep you updated and leave the issue open until then.

@monde
Copy link

monde commented Mar 15, 2023

Just throwing this out there from the Okta workforce identity side of the house. We are currently working with Hashicorp to implement Dynamic Provider Credentials https://developer.hashicorp.com/terraform/cloud-docs/workspaces/dynamic-provider-credentials for the Okta Terraform Provider in Terraform Cloud using their Workload Identity Token https://developer.hashicorp.com/terraform/cloud-docs/workspaces/dynamic-provider-credentials/workload-identity-tokens. The workload id token is OIDC based. We'll keep @sergiught in the loop on this work should any of this art be transferable to the customer identity side of the house.

@jdelforno
Copy link

Just throwing this out there from the Okta workforce identity side of the house. We are currently working with Hashicorp to implement Dynamic Provider Credentials https://developer.hashicorp.com/terraform/cloud-docs/workspaces/dynamic-provider-credentials for the Okta Terraform Provider in Terraform Cloud using their Workload Identity Token https://developer.hashicorp.com/terraform/cloud-docs/workspaces/dynamic-provider-credentials/workload-identity-tokens. The workload id token is OIDC based. We'll keep @sergiught in the loop on this work should any of this art be transferable to the customer identity side of the house.

I appreciate the effort you're going to, to accomplish that however, I'd imagine the vast majority of us don't want to sign up with Hashicorps Terraform Cloud. Especially inline with existing CI/CD tools that we're all invested in and in lieu of corporate requirements/procurement getting in the way.

Is there any chance of having a OIDC connection without the bells and whistles as a first step?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
🌱 feature New feature or request
Projects
None yet
Development

No branches or pull requests

4 participants