Add image digests #214
Comments
|
This is a good idea. For reference, the currently supported policy markers are here: https://fluxcd.io/docs/guides/image-update/#configure-image-update-for-custom-resources I can't think of any reason this wouldn't work for (Flux doesn't care what value is in the field and it's not doing any comparison against the current value, so that still makes sense... it seems like there aren't any problems that can't be solved with this idea 👍 ) |
|
Extracting the digest information from the repository is achievable, it's just that we would need to also store this information in our embedded badger database together with the tags that would reference it. This would most likely yield in a breaking change on the side of the IRC. I've been thinking about how to make this work but couldn't really come up yet with a good solution just yet. An implementation for #202 would also touch on how/what we store in the database so it might make sense to include that in the conversation as well.
That's kind of how I imagine it would work. |
The new API field `.status.latestDigest` in the `ImagePolicy` kind stores the digest of the image referred to by the the `.status.latestImage` field. This new field can be used to pin an image to an immutable descriptor rather than to a potentially moving tag, increasing the security of workloads deployed on a cluster. The goal is to make use of the digest in IAC so that manifests can be updated with the actual image digest. This commit changes the format of the data stored in the caching badger database from a list of strings to a list of `database.Tag` objects where each tag carries a tag name and a digest value. `ImageRepositoryReconciler` now fetched the digest of each image+tag when it scans the registry for new tags. To accomplish this it issues a HEAD request against the registry for each tag with the response carrying the digest in the headers. Since this is a potentially expensive operation involving network roundtrips for each tag, a goroutine is spawned for each HEAD request to parallelize the fetching process. Migration from the old database format to the new one is taken care of by the `badger.unmarshal` function which falls back to trying to unmarshal the data into a string slice in case the attempt to unmarshal it into a `database.Tag` slice fails. Subsequent `SetTags` calls then store the data in the new format. Because of its potential to significantly increase the amount of network requests, the feature is disabled by default and can be enabled using a feature flag for now. closes #214 Signed-off-by: Max Jonas Werner <mail@makk.es>
The new API field `.status.latestDigest` in the `ImagePolicy` kind stores the digest of the image referred to by the the `.status.latestImage` field. This new field can be used to pin an image to an immutable descriptor rather than to a potentially moving tag, increasing the security of workloads deployed on a cluster. The goal is to make use of the digest in IAC so that manifests can be updated with the actual image digest. This commit changes the format of the data stored in the caching badger database from a list of strings to a list of `database.Tag` objects where each tag carries a tag name and a digest value. `ImageRepositoryReconciler` now fetched the digest of each image+tag when it scans the registry for new tags. To accomplish this it issues a HEAD request against the registry for each tag with the response carrying the digest in the headers. Since this is a potentially expensive operation involving network roundtrips for each tag, a goroutine is spawned for each HEAD request to parallelize the fetching process. Migration from the old database format to the new one is taken care of by the `badger.unmarshal` function which falls back to trying to unmarshal the data into a string slice in case the attempt to unmarshal it into a `database.Tag` slice fails. Subsequent `SetTags` calls then store the data in the new format. Because of its potential to significantly increase the amount of network requests, the feature is disabled by default and can be enabled using a feature flag for now. closes #214 Signed-off-by: Max Jonas Werner <mail@makk.es>
The new API field `.status.latestDigest` in the `ImagePolicy` kind stores the digest of the image referred to by the the `.status.latestImage` field. This new field can be used to pin an image to an immutable descriptor rather than to a potentially moving tag, increasing the security of workloads deployed on a cluster. The goal is to make use of the digest in IAC so that manifests can be updated with the actual image digest. This commit changes the format of the data stored in the caching badger database from a list of strings to a list of `database.Tag` objects where each tag carries a tag name and a digest value. `ImageRepositoryReconciler` now fetched the digest of each image+tag when it scans the registry for new tags. To accomplish this it issues a HEAD request against the registry for each tag with the response carrying the digest in the headers. Since this is a potentially expensive operation involving network roundtrips for each tag, a goroutine is spawned for each HEAD request to parallelize the fetching process. Migration from the old database format to the new one is taken care of by the `badger.unmarshal` function which falls back to trying to unmarshal the data into a string slice in case the attempt to unmarshal it into a `database.Tag` slice fails. Subsequent `SetTags` calls then store the data in the new format. Because of its potential to significantly increase the amount of network requests, the feature is disabled by default and can be enabled using a feature flag for now. closes #214 Signed-off-by: Max Jonas Werner <mail@makk.es>
Would be good to have something like:
{"$imagepolicy": "<policy-namespace>:<policy-name>:digest"}resolving to image digest, for instance@sha256:foobar{"$imagepolicy": "<policy-namespace>:<policy-name>:tagWithDigest"}resolving to image tag with digest, for instancev0.1.5@sha256:foobarThe text was updated successfully, but these errors were encountered: