concourse-pipeline-resource

concourse-pipeline-resource copied to clipboard

Now that fly supports auth via oauth token, this resource should be able to authenticate with an oauth token endpoint and client credentials as an alternative to basic auth. If you all are interested in this feature, I'd be happy to work up a patch.

cc @chendrix

@jmcarp I would love to see this, would you have time to work on it ?

I'm a bit confused here @jmcarp. fly only supports login with a bearer token which is generated after completing a manual OAuth flow - so how would this resource get the token to begin with? By manually logging in every 24h and copying the bearer token to a secret backend?

Concourse used to support a flow with personal access tokens, but has since removed the feature for security reasons. Was the plan to use that feature?

any news about supporting OAuth login method ?

There is great support for basic auth but no support for other providers. Will this be added?

@pivotal-jwinters Does https://github.com/concourse/concourse/issues/2936 have any impact on this?

Yeah concourse/concourse#2936 would definitely help enable this workflow. The only thing left to figure out would be how do we map clients to api actions.

We also came across this ever since we closed up basic auth and decided to go with Keycloak. Is there any hope this will be implemented any time soon? Thanks!

For configuring pipelines on your own cluster, https://github.com/concourse/rfcs/pull/31 (PR: https://github.com/concourse/concourse/pull/4708) will be able to replace the use of this resource type entirely and not require any auth config at all. Won't help for the rare occasion when you're configuring pipelines on a different cluster though.

It seems like someone over there raised my issue already... I currently use GitOps and have a repo with all my pipelines. Each type of build has a template, and I just use a separate pipelines.yaml file to declare my pipelines with a template and all its parameters. As far as I understand, that PR will just spread everything all over the place, and will make it harder to initialize the pipelines with GitOps and templates... So this issue might really still have relevance.

@dave08

As far as I understand, that PR will just spread everything all over the place, and will make it harder to initialize the pipelines with GitOps and templates... So this issue might really still have relevance.

I'm not sure how you came to this conclusion - would you mind explaining? A set_pipeline step just replaces a put step with one that doesn't require credentials, because it's a natively supported action. How does this distinction result in 'spreading everything all over the place'? Are you trying to configure pipelines across multiple separate Concourse clusters or something? (Which is not supported by the set_pipeline step.)