search

cloudfoundry-community / cf-resource

Concourse resource for interacting with Cloud Foundry
Apache License 2.0
35 stars 63 forks source link

WIP: Provide runtime generated credentials through credentials file #77

Closed tenjaa closed 5 years ago

tenjaa commented 5 years ago

A first draft how a solution for #76 could look like. I dont expect this to be merged directly. It should be a basis for discussion how to solve the problem given in #76.

x6j8x commented 5 years ago

Instead of passing a single file one could simply detect if the value of a parameter points to a file in the working directory and replace the name with its contents.

vito commented 5 years ago

Thanks for taking a crack at this, and sorry for the long wait!

What's here makes sense, except I think the problem extends to check too, which can't depend on a task or anything generating files for it.

Could these credentials instead come from a credential manager (assuming something like https://github.com/concourse/rfcs/pull/21 exists)? What does a task that fetches these credentials typically look like?

tenjaa commented 5 years ago

@vito thanks for the reply!

As far as we could see the check doesn't do anything at all. It is just printing an empty array without using the provided credentials at all. So what should be the issue there?

Using a credentials manager would not really solve our problem. Yes it might be possible but also concourse isn't the only CI/CD tool used I am not sure we can expect a deep integration there.

The task fetching the credentials is usually just some curl + jq. But that is a custom service therefore it won't make sense to integrate it directly into the resource.

vito commented 5 years ago

As far as we could see the check doesn't do anything at all. It is just printing an empty array without using the provided credentials at all.

Ah, lame, I forgot this resource is only partially implemented. Technically it should also be able to detect whether the app is pushed and such.

I'm still not quite sure about merging this. We're going to be extracting all of our base resource types from Concourse soon (https://github.com/concourse/rfcs/pull/30), so at that point there won't be much difference between running our "official" version and running your own fork, since we don't change this resource type very often. It's entirely community-maintained and we've been trying to let CloudFoundry own it instead of us. Based on your workflow it sounds like you could potentially have your own variant that does the credential fetching for you, so you don't even need the separate task. :thinking:

The main reason I'd rather not merge it is it's kind of leveraging the fact that this resource isn't properly implemented. A proper implementation should be able to support check, get, and put. IMO it's important that our core resource types be 'exemplary' as people will use them as a reference point when designing their own resources. If your fork configured the location to fetch the credentials from, it could fetch them during check too (in theory).

Does that make sense? :sweat_smile:

tenjaa commented 5 years ago

Thanks for the explanations and yes it does make sense. We will look into other solutions then.