deck should not assume authentication for logs

[0xmichalis]

deck today uses basic auth for getting the logs from Jenkins (this assumes that Jenkins is setup with restricted access) whereas since it runs inside a pod, it can reuse its service account token to authenticate for accessing pod logs. Instead of requiring credentials for Jenkins (or any other external system), it should use a location accessible to it w/o auth where the logs are accessible for jobs of agent != "kubernetes", eg. GCS, S3, or maybe the Jenkins server is publicly available. Given that, we could get rid of all Jenkins-specific options and simply use a URL template in the prow config similar to what plank uses today for setting up github context (see #3223)

@spxtr @fejta thoughts

[0xmichalis]

/area prow

[0xmichalis]

where the logs are accessible for jobs of agent != "kubernetes"

This may also be useful for pods, since the GC interval is tight enough (24h today) but artifacts are likely longer-living and pods need to push artifacts out to somewhere anyway.

[0xmichalis]

Fixing this issue will also help in reusing ProwJobs for integrating any kind of external system by simply adding a new controller that will pick up plank's work for such external system, w/o having any external logic inside the core prow components.

[spxtr]

@spxtr @fejta thoughts

I agree, and using a URL template + a k8s service sounds like a reasonable idea.

[0xmichalis]

Another option to not assuming auth that generically covers at least basic auth and token auth is to have an --external-config-path option where we mount a secret that contains http headers which are applied in deck on every request to the url template.

[0xmichalis]

Yeah, now I think that the best option is to expose the log endpoint from the jenkins operator where we already have auth, and use a k8s service. Deck then gets a map of {agent -> url} from the config where we have {"jenkins": "jenkins-operator"} and proxies the request.

[0xmichalis]

/assign