-
Notifications
You must be signed in to change notification settings - Fork 2.3k
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
fix containerized function mounts issue #4489
fix containerized function mounts issue #4489
Conversation
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: natasha41575 The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
Some minor comments. Looks great! |
@natasha41575: This PR has multiple commits, and the default merge method is: merge. 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. |
I poked around the history of the problem file, and it seems to me this never worked. Is that correct? If so, if we were to release this PR, it would introduce a new security issue that (intended or not) we didn't have before. It looks like the feature was originally intended to have restrictions on the path, but that did not get implemented: #1902
The way Plugin Graduation proposes to handle this is through Catalog, where the Catalog entry must specify allowed mounts. Inline config like what we're turning on here actually wouldn't be supported at all anymore:
|
It seems that this is the case, and I agree that you're right, it probably isn't great to allow an unrestricted path to be mounted in the container. However, this lack of mounts would block usage of the render-helm-chart KRM function for local charts and I don't think it would be practical to wait for the Plugin Graduation and Catalog to be completed before asking users to migrate from the builtin Helm plugin. WDYT about restricting mounted paths to the same load restrictions as all other paths (i.e. it must be in the current kustomization directory)? If we do that, would that alleviate your concerns regarding security? |
Yes, this would work for me. |
3807213
to
943e3d9
Compare
943e3d9
to
35d6f33
Compare
@KnVerey awesome, PR is updated, with a check to ensure that the mounted paths are in the current directory. I added a test |
5f65d69
to
98ccc5e
Compare
As part of #4564 I noticed that it seems like some Docker-based tests do run in CI. But only the ones in cmd/config, only if they're gated with |
56a5aab
to
6f56f95
Compare
@@ -49,7 +49,9 @@ func (l *Loader) Config() *types.PluginConfig { | |||
|
|||
// SetWorkDir sets the working directory for this loader's plugins | |||
func (l *Loader) SetWorkDir(wd string) { | |||
l.pc.FnpLoadingOptions.WorkingDir = wd | |||
if wd != string(filepath.Separator) { | |||
l.pc.FnpLoadingOptions.WorkingDir = wd |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Without this change, TestFnContainerEnvVars
fails with the error couldn't execute function: root working directory '/' not allowed
. ldr.Root()
returns "/"
when run at the root-level, i.e. whenever we do th.Run(".")
in our tests. If we don't set the working dir here, then the function filter uses the current working directory, which I believe is correct behavior in the cases that hit this problem.
Alternatively I think we could rewrite TestFnContainerEnvVars
so that it does th.Run("dir")
or something, and then we won't have to have this change here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm, but isn't this just bypassing a real restriction we have in our function code? In other words, won't it really enable the root directory to be used as valid plugin load location, effectively allowing plugins from anywhere on the disk?
If we don't set the working dir here, then the function filter uses the current working directory, which I believe is correct behavior in the cases that hit this problem.
Can you explain more why you believe this is correct? My inclination would be that it's easier to understand what's happening if the behavior is always the same (kustomization root, not invocation dir).
Alternatively I think we could rewrite TestFnContainerEnvVars so that it does th.Run("dir") or something, and then we won't have to have this change here.
Is it true that the tests in question are always using a virtual filesystem, and that's why it's not bad for the Kustomization dir to be the root? If so, that change will make the tests more realistic, right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🤦♀️ you're right on all points. I think my brain was in another location when I wrote this part, for some reason I was thinking of the working directory as the kustomization root, which is obviously not the case and is the whole reason we are doing this anyways.
I will update the test.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Test updated! I had to change it to use a temporary directory in the real file system because it's shelling out to docker and needs the working directory to be a real one.
6f56f95
to
6ccb493
Compare
473d005
to
864b0e0
Compare
864b0e0
to
94c2cca
Compare
94c2cca
to
96977a1
Compare
According to the logs, the docker tests are running in the linux job but not the mac one. Filed #4579 |
28f5cce
to
dfaa43c
Compare
@@ -0,0 +1,27 @@ | |||
replicaCount: 1 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why two values files? And do we actually need the whole chart for the purposes of the test?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pared this down to a minimal example!
api/krusty/fnplugin_test.go
Outdated
assert.NoError(t, err) | ||
|
||
testDir := filepath.Join(path, "testdata", "fnmounts") | ||
command := exec.Command("kustomize", "build", testDir, "--enable-alpha-plugins") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why is this test exec'ing Kustomize instead of using the test framework? How do we know the binary that will be found corresponds to the version of the code we think we're testing?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Originally I was trying to copy the entire testdata/fnmounts directory into the temp directory where the test framework was running, which turned out to be a headache.
But with a pared down helm chart (per your other suggestion), this is much easier to do with the test framework. Updated!
5ac4df0
to
008ca9a
Compare
008ca9a
to
e0166b5
Compare
/lgtm |
Fix #4290
Kustomize was not mounting files into containerized functions directly because the
StorageMounts
field was not being properly propagated to the function filter.This PR allows users to use the
StorageMounts
fields, with the following requirements:As a side note, if we are going to be promoting functions in kustomize we should probably build up a strong test suite for containerized functions and run those tests in CI. All tests needing docker are currently being skipped.
/cc @yuwenma
/cc @KnVerey