-
Notifications
You must be signed in to change notification settings - Fork 505
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
Adding setcap image so that capabilities can be applied to #1684
Conversation
Welcome @vinayakankugoyal! |
Hi @vinayakankugoyal. 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 @justaugustus |
/ok-to-test |
/cc @BenTheElder |
6c8bc20
to
c79082c
Compare
/cc @liggitt |
/cc @dekkagaijin |
/cc saschagrunert |
Thanks @dims! A few thoughts (I am a newbie compared to all the people on the review so might be completely wrong)
|
The binary sounds OK to me I suppose, but I think either way we want this in a build-time image only, it's sort of useless at runtime, just extra image size..? It could be in say kube-cross if we don't want a new image? But I think? the build will perform better if it's in a small image for the |
Wondering if we could use this https://github.com/scionproto/docker-caps |
We typically prefer to have all images hosted under our infra:
Though we have precedent for essentially just mirroring an image (we're doing this for some e2e images) so we can still pull from k8s.gcr.io without necessarily having to create a new image from scratch. aside: the approach in that project's readme is not ideal, |
FWIW: I also think we can easily iterate on the implementation of the image as soon as we can agree on the existence of an image for this purpose. If we can get consensus on that I'm not super concerned with how it is implemented, it merely needs to provide the |
Good catch, although we would still be able to do, since we use buildx.
|
I personally like the idea of the having a separate image as its easy to reason about its purpose. Adding it to go-runner and kube-cross only increases their size unnecessarily as you mentioned. |
export DOCKER_CLI_EXPERIMENTAL := enabled | ||
|
||
build: | ||
ifneq ($(ARCH),amd64) |
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.
Let's do not silently assume that we're running on amd64.
ifneq ($(ARCH),amd64) |
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.
Do we build these images on another arch?
NOTE: this is from multiple other makefiles in this repo:
ifneq ($(ARCH),amd64) |
ifneq ($(ARCH),amd64) |
release/images/build/debian-base/Makefile
Line 115 in aab9759
ifneq ($(ARCH),amd64) |
IMO if we consider this a problem this needs a cleanup orthogonal to this PR and the discussion around what way to use setcap
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.
Do we build these images on another arch?
Not in the CI, but when developing those images locally different machines using different architectures would result in different outputs.
IMO if we consider this a problem this needs a cleanup orthogonal to this PR and the discussion around what way to use setcap
Right now I'm working on cleaning up the debian-base image in #1909. Sure, I'm happy to follow-up on that later on.
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.
fair enough! thanks :-)
/approve |
/hold |
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.
/lgtm
Code looks good from my point of view. I'm not sure if @justaugustus wants to chime in, I don't have the full context of the origin of this image. Feel free to lift the hold if we assume everyone is happy. 🙂
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: BenTheElder, dekkagaijin, saschagrunert, vinayakankugoyal 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 |
@vinayakankugoyal can you please edit the PR description to mention a release-note that we added this image? |
Forgot to add that I tested it with cloud build and that works.:
Then used the image in a multistage docker build and verified the capabilities. (binary name and project location have been redacted)
|
Stephen is OOO for about a week (until the 17th), I'm inclined to move forward for now, having this is a net improvement over alternative approaches in k/k, we can start iterating on the build logic xref #1909 |
kubernetes binaries.
What type of PR is this?
/kind feature
What this PR does / why we need it:
This PR creates an image based on debian-base with libcap2-bin installed so that we can apply capabilities to k8s binaries like kube-apiserver. This will allow kube-apiserver to bind to port lower than 1024 without requiring it to run as root.
Which issue(s) this PR fixes:
None
Special notes for your reviewer:
For reference please see: kubernetes/kubernetes#96134
Does this PR introduce a user-facing change?