-
Notifications
You must be signed in to change notification settings - Fork 39.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
Enable kustomize in kubectl #70875
Enable kustomize in kubectl #70875
Conversation
Hi @Liujingfang1. Thanks for your PR. I'm waiting for a kubernetes member to verify that this patch is reasonable to test. If it is, they should reply with Once the patch is verified, the new status will be reflected by the I understand the commands that are listed here. 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. |
/cc @monopole |
@@ -452,7 +457,10 @@ func ExpandPathsToFileVisitors(mapper *mapper, paths string, recursive bool, ext | |||
if err != nil { | |||
return err | |||
} | |||
|
|||
if isKustomizationDir(path) { |
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.
I don't think this is backwards compatible. Anyone using kubectl create -f DIR
will see something different happen after this change lands, which means existing CLI workflows could break.
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.
I just tested the behaviour. kubectl create
and kubectl apply
both fail with a kustomization.yaml present:
error: error validating ".../k8s.io/examples/guestbook-go/kustomization.yaml": error validating data: [apiVersion not set, kind not set]; if you choose to ignore these errors, turn validation off with --validate=false
It looks like we have a separate issue, which is that we don't validate all files before starting to apply, which is contrary to what I would have expected.
But I don't think users can be using kubectl create -f DIR
or kubectl apply -f DIR
today with a dir containing kustomization.yaml.
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.
@smarterclayton The existing kubectl doesn't work with directories with a kustomization.yaml as @justinsb explained. With this PR, kubectl will be able to recognize a directory with a kustomization.yaml. For any directories without kustomization.yaml, there is no change in kubectl's behavior.
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.
If someone has validate=false off, what happens? If it also fails, then my primary concern is addressed.
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.
With validate=false, it fails with similar error
error: unable to decode "kustomization.yaml": Object 'Kind' is missing in `<truncated>`
a401eca
to
b426d83
Compare
/ok-to-test |
90bac14
to
3c4901b
Compare
As discussed offline, we can remove the opt out. I added a commit for that. @pwittrock PTAL |
/retest |
2 similar comments
/retest |
/retest |
/test pull-kubernetes-godeps |
@@ -463,7 +471,10 @@ func ExpandPathsToFileVisitors(mapper *mapper, paths string, recursive bool, ext | |||
if path != paths && ignoreFile(path, extensions) { | |||
return nil | |||
} | |||
|
|||
if filepath.Base(path) == constants.KustomizationFileName { |
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.
This will be changed to check the GVK of the kustomization file in an immediate follow up.
fSys := fs.MakeRealFS() | ||
f := k8sdeps.NewFactory() | ||
var out bytes.Buffer | ||
cmd := build.NewCmdBuild(&out, fSys, f.ResmapF, f.TransformerF) |
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.
In an immediate follow up this should be a library that takes options.
/approve |
/lgtm |
Follow up issues tracked here: |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: Liujingfang1, pwittrock, thockin 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 |
/hold cancel |
@soltysh removing hold. @JiangtianLi is working on a follow up. |
/test pull-kubernetes-integration |
/test |
/test pull-kubernetes-e2e-gce |
I'm only just learning about kustomize, but I am a bit alarmed about what I'm reading and the implications for this PR. With this PR, can I just pwn the world by putting a malicious kustomize.yaml in a popular manifest examples site somewhere? Consider: # kustomize.yaml - don't try this at home.
secretGenerator:
- name: allyourbase
commands:
# or any other malicious command
foo: "echo backdoorkey >> $HOME/.ssh/authorized_keys" In particular, with this PR, I think |
FWIW I think that particular issue will be covered by
kubernetes-sigs/kustomize#683.
This PR as-is was merged early in the current release cycle so it will not
be in any releases (not even an alpha) for a bit.
…On Thu, Jan 10, 2019 at 7:52 PM Angus Lees ***@***.***> wrote:
I'm only just learning about kustomize, but I am a bit alarmed about what
I'm reading and the implications for this PR. With this PR, can I just pwn
the world by putting a malicious kustomize.yaml in a popular manifest
examples site somewhere?
Consider:
secretGenerator:
- name: allyourbase
commands:
# or any other malicious command
foo: "echo backdoorkey >> $HOME/.ssh/authorized_keys"
In particular, with this PR, I think kubectl apply -f http://that/repo"
suddenly becomes able to modify the *local* machine, not just the target
cluster, even with --dry-run`.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#70875 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AA4Bq4qCEXWAABrseJFWln6ACEJJAxlkks5vCApugaJpZM4YW_gT>
.
|
Discussion of changes to the UX integration were raised and are being talked through in kubernetes/kubectl#570. The outcome of those discussions will be folded into the KEP before reintegrating: kubernetes/enhancements#684 Additionally there were some security concerns raised that require changes, such as limiting process callouts: kubernetes-sigs/kustomize#683. The new capabilities added by kustomize will be reviewed from a security perspective prior to reintegration. PR to revert: #72805 |
What type of PR is this?
/kind feature
What this PR does / why we need it:
This PR is the implementation of KEP to enable kustomize in kubectl.
When
-f <dir>
is passed to a kubectl command, it will look for akustomization.yaml
file. Ifkustomization.yaml
is found, a kustomize build will be run to get the list of expanded resources. This list of resources is then passed to kubectl commands. If there is nokustomization.yaml
in the directory, kubectl will behave the same as current.To apply a kustomization directory
To get resources of a kustomization directory applied to a cluster
To delete a kustomization directory applied to a cluster
Special notes for your reviewer:
This PR contains 6 commits.
Kubectl will have kustomization enabled by default.
Other
cli-runtime
consumers may choose if they want to enable or not kustomization by a Boolean variable.Does this PR introduce a user-facing change?:
NONE