-
Notifications
You must be signed in to change notification settings - Fork 2.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
resources: support remote files #970
Comments
|
Jingfang Liu <notifications@github.com> writes:
`resources` should be from local disks, which is different from the bases. We don't plan to support remote files for resources.
What you could do is to submit a PR to [kubernetes-csi/external-provisioner](https://github.com/kubernetes-csi/external-provisioner/tree/master/deploy/kubernetes), adding a kustomization.yaml there.
Then you can use it as a remote base.
I had thought of that, but it doesn't make sense to me. Why should
upstream repos have to had a kustomization.yaml file when they don't
actually use kustomize?
|
Can you explain why? What is the problem with loading remote resources? If a base kustomization.yaml is loaded from a remote server then it eventually loads resources from a remote server too, right? Then why can't we just load remote resources directly, bypassing loading a base? |
Forcing people to have this kustomization.yml on their repo makes the remote base feature pretty much useless in real life scenarios. The idea of being able to load some yaml from whatever repo on github, untouched, and create variants from it will not happen if we expect repo maintainers to create kustomizations. In an other hand, if we allow remote resources we automatically give access to any resources to all kustomize users. A work around would be to use git submodules and a kustomization.yml file but that's ugly. |
I would like to consume resources directly from URL. I don't see a security issue if the manifest from the resource is audited before use, and I don't see a good technical reason why it cannot be achieved. Could you clarify why there is no plan for this? I even don't mind tackling the code on my spare time, but I need a longer explanation than |
This is my need for kustomize to support remote files. I would like to manage my k8s resources in a consistent and declarative way as much as possible. I'm trying out to not be dependent on helm. Kustomize is definitely working out for me at the moment. However, being able to reference remote file urls will help with referencing 3rd party yamls such as for cert-manager, ingress-nginx, jaeger, and kubernetes dashboard. At this time, I'm pulling the code into my repository. Is there a cleaner way that I don't know about? |
Has anyone brought this up at the kustomize sig meeting. Seems like it would be trivial to make a pr to push the discussion further but I agree it's not really clear why from @Liujingfang1 remote resources couln't be done. |
Reflected this over to kubernetes/kubernetes#82459 in case kustomize development has moved there. |
Another fun example would be installing knative https://github.com/knative/serving/releases/tag/v0.8.1 Maybe should provide a kustomization.yaml but as is they provide a couple of yamls you can combine manually love to refernce them directly from my kustomziation.yaml rather than mirroring. |
I see an example with a remote
https://github.com/kubernetes-sigs/kustomize/blob/master/examples/remoteBuild.md#remote-targets It doesn't work. |
@sbose78 Which version do you use? I checked with HEAD and it works. |
@Liujingfang1 does that work for resources that aren't a base? Resources which are bases are fine, it's for the rest of the resources that remote data could be useful. |
@Liujingfang1 does not work for me, ( kubectl v1.16.3, it should use 2.0.3 -> https://github.com/kubernetes/kubernetes/blob/release-1.16/go.mod#L487)
kubectl kustomize .
I tried standalone kustomize binary 3.4.0 and its working also with |
Same here, I need this feature, and needing the kustomize.yaml on the remote side is not possible. |
@Liujingfang1 Also putting in my support for this feature. I've had PRs on a couple of projects now trying to get maintainers to add Latest example: Here Google provides a DaemonSet for installing Nvidia drivers on nodes which I would like to have included in my build, but it's not possible because I can't use their file directly and they don't have a The first reply to this issue that
also doesn't really apply anymore since |
Any update on this issue? I also need this for quite a simple use case: I want to install the Jaeger operator on one of my clusters, so far they only provide yaml files to run the required resources but no kustomize related config so I can't import the base. I only want to have something like the following in my own config:
For now, if I understand well, the best solution I have is to copy the remote file content into a local file. |
Is this supported now? |
For anyone stumbling upon this issue while googling: It is supported now, but the documentation is outdated as of today as this Just put a regular URL in the resources section, example: apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
- https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml |
It seems that there is not way to use apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
- git@github.com:argoproj/argo-cd.git/manifests/crds/application-crd.yaml?ref=v2.1.3 with error:
While following will work (mind that apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
- git@github.com:argoproj/argo-cd.git/manifests/crds?ref=v2.1.3 In my use-case git-repo is private, thus I can't use 'https'-protocol for fetching individual files. Why there is a limitation for individual files for |
This is a bit of a weird one to stumble upon. Getting the file from git would be a great advantage. With the git protocol, we could use the commit hash, so you would also be confident someone sneaky isn't changing the files, and have some form of verification. In the https mode, that's just a URL, someone could change that file and you probably wouldn't know, or get any indication you just built something malicious |
Two years later and running into the issue @karpoftea described above. Really unknown why the limitation is imposed on the git loader. The https loader is useless in an enterprise context, where storing kustomize files elsewhere is needed... |
Has there been any progress here? |
The original issue was fixed years ago as this example illustrates:
References to remote directories also works. For references to remote files in private repos using schemes other than file or https, I suggest creating a new issue. However, given kustomize's preference for folder refs and its restrictions on loading resources not in or below the root folder, even the support for remote files already provided seems questionable to me. https://kubectl.docs.kubernetes.io/faq/kustomize/#security-file-foo-is-not-in-or-below-bar |
Currently,
resources
entries must be local files. It would be useful to allow references to remote files, for example a file served by a HTTPS server.The use case I have in mind is about pulling the
rbac.yaml
files that Kubernetes-CSI publishes for each sidecar app into a deployment:https://github.com/kubernetes-csi/external-provisioner/blob/master/deploy/kubernetes/rbac.yaml
Originally this was suggested in #254, but that got closed by just updating the docs. #923 is related, but covers only
bases
.Pulling remote files has security implications. When using HTTPS, one has to trust the remote server and relies on HTTPS security to prevent man-in-the-middle attacks. It would be nice to support defining and checking an expected file content hash.
The text was updated successfully, but these errors were encountered: