tektoncd
Extend HTTP Resolver spec to support optional hash field
Feature request
Add an optional hash, digest, or more appropriately named field to the HTTP resolver spec in which a user provides a hash of the content at the URL. If the field is populated, http resolver would enforce that the http response's content hashes to the same value.
The http resolver could also have a configuration setting to require this field.
Use case
As a security-minded Tekton user, I prefer using resolvers which have some security guarantees. The git resolver provides guarantees via git hashes and the bundles resolver provides similar guarantees via the bundle digest. However in some cases the http resolver is necessary, but as of right now there are no mechanisms to guarantee the content received from the http request is the content I expect. Further, in order to better secure the pipelines I would like to enforce that anyone authoring pipelineruns in my cluster are using secure practices.
@aThorp96 Thanks! Shall we mark this as "help wanted" or is this something you're going to work on yourself?
@afrittoli I may work on this in the next few months but it could be a little bit before I can get around to it. No objection to the help wanted label
@lcarva @arewm From Tekton Chains and SLSA perspectice, what would be an acceptable hashing algorithm here? Would sha1 or sha256 suffice, or it there another best-practice hashing algorithm to use?
I'm wondering too if the algorithm should be the field name as well, instead of an ambiguous name like hash. For example if sha256 is used:
taskRef:
resolver: http
params:
- name: url
value: https://raw.githubusercontent.com/tektoncd-catalog/git-clone/main/task/git-clone/git-clone.yaml
- name: sha256sum
value: 2ba5253270551c0ab46dd164a3d00173c784142bcdc761a6340054854e3c3fec
sha1 is probably not ok. The remaining support for that is basically to support git commit IDs. sha256 and sha512 both work. I'm not seeing any recommendation from SLSA Provenance perspective, but I do see that the ResourceDescriptor has these:
"digest": {
"sha256": string,
"sha512": string,
"gitCommit": string,
[string]: string,
},
That implies support for multiple digest algorithms. I like your suggestion of using the name for this.
Thanks! @lcarva & @aThorp96, I will go with the solution Andrew suggested and will do:
taskRef:
resolver: http
params:
- name: url
value: https://raw.githubusercontent.com/tektoncd-catalog/git-clone/main/task/git-clone/git-clone.yaml
- name: [sha256sum | sha512sum]
value: 2ba5253270551c0ab46dd164a3d00173c784142bcdc761a6340054854e3c3fec
@zakisk @aThorp96 any reason for not doing something like the following ?
taskRef:
resolver: http
params:
- name: url
value: https://raw.githubusercontent.com/tektoncd-catalog/git-clone/main/task/git-clone/git-clone.yaml
- name: digest
value: sha512:2ba5253270551c0ab46dd164a3d00173c784142bcdc761a6340054854e3c3fec
@vdemeester , would you support only one digest algorithm? Can you clone directly with sha256? Would usability suffer if people don't know how to get the sha256? Are update tools like Renovate capable of maintaining sha256 git digests?
@arewm This is the http resolver, so I think some of your questions might not apply. Only a coincidence that the example http URL is a raw.githubusercontent.com address :)
That being said, I do agree that we must document that this is an optional parameter to the http resolver and include an example of how to get the sha256 of an arbitrary http-fetched object.
So the http resolver will fetch the target and then compute the shasum to verify? It is not fetching anything by shasum?
So the http resolver will fetch the target and then compute the shasum to verify? It is not fetching anything by shasum?
Yes! @arewm