LoadRestrictionsNone does not disable restrictions on remote bases

[814HiManny]

When using LoadRestrictionsNone I expect kustomize to be able to refer to kustomizations in git repositories that reference a configuration that is outside of the directory where the kustomization is. If I do a git clone of a repo, the LoadRestrictionsNone flag correctly works. When the same git repo is referenced via a git resource, it does not work.

kustomization.yaml

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
- https://github.com/814HiManny/kustomize/examples/transformerconfigs/images-config-outside/

Expected output

A valid yaml output

Actual output

$> kustomize build --load-restrictor LoadRestrictionsNone ktest-outside/

Error: accumulating resources: accumulation err='accumulating resources from 'https://github.com/814HiManny/kustomize/examples/transformerconfigs/images-config-outside/': yaml: line 175: mapping values are not allowed in this context': recursed accumulation of path '/private/var/folders/rh/5hvkwnmd4g3fb5dl6w0nb2vw0000gn/T/kustomize-843568672/examples/transformerconfigs/images-config-outside': security; file '/private/var/folders/rh/5hvkwnmd4g3fb5dl6w0nb2vw0000gn/T/kustomize-843568672/examples/transformerconfigs/kustomizeconfig/mykind.yaml' is not in or below '/private/var/folders/rh/5hvkwnmd4g3fb5dl6w0nb2vw0000gn/T/kustomize-843568672/examples/transformerconfigs/images-config-outside'

Kustomize version

{Version:kustomize/v4.2.0 GitCommit:d53a2ad45d04b0264bcee9e19879437d851cb778 BuildDate:2021-06-30T22:49:26Z GoOs:darwin GoArch:amd64}

Platform

macOS

[ron1]

@814HiManny FYI, I get the same error in the even simpler case with no local kustomization.yaml file. However, if I first clone the repo and then execute kustomize build, it works as expected. Note this bug is also reproducible at least as far back as kustomize 3.8.1.

FAILURE:

$> kustomize build https://github.com/814HiManny/kustomize/examples/transformerconfigs/images-config-outside --load-restrictor LoadRestrictionsNone

Error: security; file '/tmp/kustomize-203698288/examples/transformerconfigs/kustomizeconfig/mykind.yaml' is not in or below '/tmp/kustomize-203698288/examples/transformerconfigs/images-config-outside'

SUCCESS:

$> git clone https://github.com/814HiManny/kustomize 2>nul
$> echo $?
0
$> kustomize build kustomize/examples/transformerconfigs/images-config-outside --load-restrictor LoadRestrictionsNone | wc -l
27

[KnVerey]

/triage accepted

[soleares]

@814HiManny Probably no surprise but the behavior is the same using SSH. I mention it because I ran into this issue while trying to access a private repo with SSH.

$ kustomize build git@github.com:814HiManny/kustomize.git//examples/transformerconfigs/images-config-outside --load-restrictor LoadRestrictionsNone

Error: security; file '/private/var/folders/9d/w8hssg6d499cszk5s19gsx_m0000gp/T/kustomize-426654121/examples/transformerconfigs/kustomizeconfig/mykind.yaml' is not in or below '/private/var/folders/9d/w8hssg6d499cszk5s19gsx_m0000gp/T/kustomize-426654121/examples/transformerconfigs/images-config-outside'

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle stale
• Mark this issue or PR as rotten with /lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[ron1]

/remove- lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle stale
• Mark this issue or PR as rotten with /lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten

[ron1]

/remove- lifecycle stale

[ron1]

/remove- lifecycle rotten

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Reopen this issue or PR with /reopen
• Mark this issue or PR as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close

[k8s-ci-robot]

@k8s-triage-robot: Closing this issue.

In response to this:

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Reopen this issue or PR with /reopen
• Mark this issue or PR as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[saviogl]

@814HiManny Any solutions for this? Did this just get closed and that's it?

[saviogl]

/remove-lifecycle rotten

[saviogl]

/reopen

[k8s-ci-robot]

@saviogl: You can't reopen an issue/PR unless you authored it or you are a collaborator.

In response to this:

/reopen

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[KnVerey]

I apologize for causing confusion, but I should not have accepted this issue. The fact that the load restrictor cannot be bypassed, even with the flag, for remote bases is an intentional security feature.

https://github.com/kubernetes-sigs/kustomize/blob/master/api/loader/fileloader.go#L210-L211

In general, we recommend localizing remote bases for production use and subjecting them to review. This is even more critical, to the point that we require it, when the remote base requires arbitrary filesystem access. We are working on kustomize localize feature to help with workflows like this: https://github.com/kubernetes-sigs/kustomize/blob/master/proposals/22-04-localize-command.md.

We would accept documentation or warning message improvements to alleviate the confusion around this, but we will not be changing the behaviour.

/retitle LoadRestrictionsNone does not disable restrictions on remote bases

/triage unresolved
/kind documentation
/close

[k8s-ci-robot]

@KnVerey: Closing this issue.

In response to this:

I apologize for causing confusion, but I should not have accepted this issue. The fact that the load restrictor cannot be bypassed, even with the flag, for remote bases is an intentional security feature.

https://github.com/kubernetes-sigs/kustomize/blob/master/api/loader/fileloader.go#L210-L211

In general, we recommend localizing remote bases for production use and subjecting them to review. This is even more critical, to the point that we require it, when the remote base requires arbitrary filesystem access. We are working on kustomize localize feature to help with workflows like this: https://github.com/kubernetes-sigs/kustomize/blob/master/proposals/22-04-localize-command.md.

We would accept documentation or warning message improvements to alleviate the confusion around this, but we will not be changing the behaviour.

/retitle LoadRestrictionsNone does not disable restrictions on remote bases

/triage unresolved
/kind documentation
/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[k8s-ci-robot]

@814HiManny: This issue is currently awaiting triage.

SIG CLI takes a lead on issue triage for this repo, but any Kubernetes member can accept issues by applying the triage/accepted label.

The triage/accepted label can be added by org members by writing /triage accepted in a comment.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.