Replies: 2 comments 7 replies
-
Hi! plain URLs are not considered versioned sources, even if they are RESTful resources that may contain versioning in their schemes. You can use inline URLs in kustomize but the use is heavily discouraged, and in the Flux docs we provide hardening instructions that will prevent users from doing this - it's recommended to prevent this because it can circumvent source provenance verification.
Those and the provenance verification are the main advantages of using Flux sources. The only Flux source kinds at present are GitRepository, OCIRepository, Bucket, and HelmRepository (and the associated HelmChart resources that come downstream of any Helm chart source) I think there is some merit to the idea in #4359, github releases as a versioned source, because they do meet the criteria of a versioned source, but I don't know if it will be prioritized in the Flux roadmap. They do not have the advantages of OCI like cosign verification, keyless authentication workflows, but they could be a lightweight alternative. Thank you for re-raising this with more detail. Until the Flux media type is adopted by manifest publishers, there might not be any better option than to copy the manifests into your local repo and keep them versioned locally, either in your own OCI repos that you test and re-publish, or in the bootstrap/config repo copied from upstream (kept updated by a simple Makefile or script.) The very last choice option is to use an external URL reference, it has numerous disadvantages and it is not recommended for all the reasons you cited. If the Gateway API You can select a tag using It's a middle of the road option because there is certainly a lot of other content in the Gateway API repo, and it might not always be part of the tree - it could be only stitched together at release time and only in the release archives. Flux publishes its own manifests as OCI, signed with cosign keyless workflows (and projects like the Gateway API should too!) https://github.com/fluxcd/flux2/pkgs/container/flux-manifests This is the best option because release workflows that stitch things together can provide this as an additional output that can be verified with cosign; do you know if gateway-api git tree contains the standard-install.yaml anywhere, is it composed from here? https://github.com/kubernetes-sigs/gateway-api/tree/main/config |
Beta Was this translation helpful? Give feedback.
-
For the Gateway API and almost all Kubernetes CRDs you can use the Git as the source. Controllers made with kubebuilder have a crd kustomize overlay. Here is the Gateway API: https://github.com/kubernetes-sigs/gateway-api/tree/main/config/crd/standard |
Beta Was this translation helpful? Give feedback.
-
Heya,
I'm pretty new to Flux - I'm trying to install the k8s gateway API definitions. These are installed by a static yaml bundle:
https://github.com/kubernetes-sigs/gateway-api/releases/download/v1.0.0/standard-install.yaml
I guess I can set such a bundle as an inline link in a
kustomization.yaml
, however I'd like to use a Flux source instead to take advantage of caching + decoupling from reconciliation interval, trying to follow the general direction to avoid inline remote sources.Is there any way to do this if the yamls are published as a plain URL, and not in a Git or OCI repo?
Cheers
Jarrad
somewhat related: #4359
Beta Was this translation helpful? Give feedback.
All reactions