Skip to content
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

Authenticated/Authorized access to kubelet API #89

Closed
18 of 22 tasks
liggitt opened this issue Sep 12, 2016 · 30 comments
Closed
18 of 22 tasks

Authenticated/Authorized access to kubelet API #89

liggitt opened this issue Sep 12, 2016 · 30 comments
Assignees
Labels
lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. sig/auth Categorizes an issue or PR as relevant to SIG Auth.

Comments

@liggitt
Copy link
Member

liggitt commented Sep 12, 2016

Description

The kubelet API gives access to a wide variety of resources.

Allow authenticating requests to the kubelet API using any of:

  • x509 client certs
  • bearer token (validated using the TokenReview API)
  • anonymous authentication (default in 1.0-1.4)

Allow authorizing requests to the kubelet API using one of:

  • SubjectAccessReview API
  • AlwaysAllow (default in 1.0-1.4)

Progress Tracker

FEATURE_STATUS: IN_DEVELOPMENT

@liggitt
Copy link
Member Author

liggitt commented Sep 12, 2016

cc @kubernetes/sig-auth

@deads2k
Copy link
Contributor

deads2k commented Sep 13, 2016

cc @kubernetes/sig-auth

Just noting approval for the feature.

@philips
Copy link
Contributor

philips commented Sep 14, 2016

@liggitt @deads2k are y'all planning on doing this work? I am cross-tracking this on the SIG node task list.

@liggitt
Copy link
Member Author

liggitt commented Sep 15, 2016

@philips yes, I'll be doing the work

@jessfs
Copy link

jessfs commented Sep 20, 2016

Just wondering, will this be in 1.5? Trying to determine if our team needs to invest the time into securing these communications via SSH and firewall rules to prevent https://github.com/kayrus/kubelet-exploit, or if we can just hold off for a bit and utilize our existing TLS client certs once this lands.

@deads2k
Copy link
Contributor

deads2k commented Sep 21, 2016

Just wondering, will this be in 1.5?

Yes, we are targeting 1.5.

@jessfs
Copy link

jessfs commented Sep 26, 2016

@deads2k awesome, thanks!!

@alex-mohr alex-mohr added this to the v1.5 milestone Oct 4, 2016
@alex-mohr alex-mohr added sig/auth Categorizes an issue or PR as relevant to SIG Auth. sig/node Categorizes an issue or PR as relevant to SIG Node. labels Oct 4, 2016
k8s-github-robot pushed a commit to kubernetes/kubernetes that referenced this issue Oct 7, 2016
Automatic merge from submit-queue

Proposal: kubelet authentication/authorization

Proposal for kubernetes/enhancements#89
@kevin-wangzefeng
Copy link
Member

/cc @kubernetes/huawei

k8s-github-robot pushed a commit to kubernetes/kubernetes that referenced this issue Oct 26, 2016
Automatic merge from submit-queue

kubelet authn/authz

Implements https://github.com/kubernetes/kubernetes/blob/master/docs/proposals/kubelet-auth.md

Part of [Authenticated/Authorized access to kubelet API](kubernetes/enhancements#89) feature
k8s-github-robot pushed a commit to kubernetes/kubernetes that referenced this issue Nov 6, 2016
Automatic merge from submit-queue

Cleanup auth logging, allow starting secured kubelet in local-up-cluster.sh

Cleanup for kubernetes/enhancements#89
@idvoretskyi
Copy link
Member

Does this feature target alpha for 1.5?

@deads2k
Copy link
Contributor

deads2k commented Nov 17, 2016

Does this feature target alpha for 1.5?

@idvoretskyi at least alpha

@erictune @liggitt This mirrors the mechanism we've used in OpenShift since 1.0. Want to call it beta?

@liggitt
Copy link
Member Author

liggitt commented Nov 17, 2016

I'd be comfortable with beta. It is built on top of two beta APIs, and has been tested. The remaining work is automated load testing and default enablement in the various install/setup methods

@erictune
Copy link
Member

No objection to beta. Ask node team too?

On Thu, Nov 17, 2016 at 5:29 AM, Jordan Liggitt [email protected]
wrote:

I'd be comfortable with beta. It is built on top of two beta APIs, and has
been tested. The remaining work is automated load testing and default
enablement in the various install/setup methods


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#89 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AHuudnmBmvnWB6MaZFzXHqy96__HdUdGks5q_FbRgaJpZM4J65Mz
.

@derekwaynecarr
Copy link
Member

I am a lead on @kubernetes/sig-node and agree this should be beta.

michelleN pushed a commit to michelleN/community that referenced this issue Nov 30, 2016
Automatic merge from submit-queue

Proposal: kubelet authentication/authorization

Proposal for kubernetes/enhancements#89
@spiffxp
Copy link
Member

spiffxp commented Dec 1, 2016

I'm removing the team/SIG-Node label given that SIG-Auth is listed as the owner in the 1.5 feature spreadsheet; if we're using labels to describe areas of overlap then we need something else in these issues to identify owner

@spiffxp spiffxp removed the sig/node Categorizes an issue or PR as relevant to SIG Node. label Dec 1, 2016
@idvoretskyi
Copy link
Member

@liggitt can you confirm that this item targets stable in 1.6?

@idvoretskyi idvoretskyi modified the milestones: next-milestone, v1.5 Dec 13, 2016
@liggitt
Copy link
Member Author

liggitt commented Dec 19, 2016

@liggitt can you confirm that this item targets stable in 1.6?

Yes

@idvoretskyi idvoretskyi added stage/stable Denotes an issue tracking an enhancement targeted for Stable/GA status and removed (deprecated label - do not use) beta-in-1.5 labels Dec 19, 2016
@idvoretskyi idvoretskyi modified the milestones: v1.6, next-milestone Dec 19, 2016
@idvoretskyi idvoretskyi added stage/beta Denotes an issue tracking an enhancement targeted for Beta status and removed stage/stable Denotes an issue tracking an enhancement targeted for Stable/GA status labels Jan 30, 2017
@liggitt
Copy link
Member Author

liggitt commented Jan 30, 2017

keeping in beta status until the TokenReview and SubjectAccessReview APIs move to stable (now targeting 1.7)

@grodrigues3 grodrigues3 modified the milestones: next-milestone, v1.6 Feb 3, 2017
@grodrigues3 grodrigues3 removed the stage/beta Denotes an issue tracking an enhancement targeted for Beta status label Feb 3, 2017
@grodrigues3
Copy link
Contributor

@liggitt @idvoretskyi moving to next milestone then

@joantune
Copy link

joantune commented Jul 19, 2017

Hi guys!

So, what's the status on this? I saw some PR for docs which seems to have changed.

Having a secure kubernetes cluster right out of kubeadm 'box' would be great. On a sidenote can one use calico or any of the Networking and Network Policy addons for this? Clearly AFAIK VXLAN based ones are insufficient as VXLAN doesn't provide security (please correct me if i'm wrong) but I'm thinking something like Calico could help? would a properly configured Calico be enough to make the These connections are not currently safe to run over untrusted and/or public networks warning from the apiserver -> nodes, pods, and services section that lives here obsolete?

@luxas
Copy link
Member

luxas commented Jul 19, 2017

Having a secure kubernetes cluster right out of kubeadm 'box' would be great

That is the case. kubeadm uses the latest stable security features for pretty much every release.

Regarding the other questions you have, I don't think they are very relevant to this feature. This feature is about locking down the kubelet API endpoint, not network (Pod2Pod, Node2Node) communication.

@liggitt I guess we could close this. Stable in v1.6 which was released some time ago. Most providers (like kubeadm) enable this by default.

@joantune
Copy link

joantune commented Jul 19, 2017

Regarding the other questions you have, I don't think they are very relevant to this feature. This feature is about locking down the kubelet API endpoint, not network (Pod2Pod, Node2Node) communication.

Locking it down as in an access control applied to the level of the kubelet API endpoint itself, right? not preventing access from it, because I can still pretty much do a wget --no-check-certificate https://<ip>:10250 on the nodes etc.
It would be great to have a way to only access this through ssh tunnels or perhaps HTTP client based certificates, no? although ssh tunnels sound more secure (as the port wouldn't be available from the outside)

In no way I have considered the implications/work of such a feature given Kubernetes architecture. Simply by my book no port to connect to available is better than having it available

@luxas
Copy link
Member

luxas commented Jul 19, 2017

Please read https://github.com/kubernetes/kubernetes.github.io/blob/master/docs/admin/kubelet-authentication-authorization.md

The kubelet port at https://<ip>:10250 can with this feature (in the kubeadm case) only be accessed by client certificates signed by the cluster CA with O=system:masters, which basically means API Servers are the only ones that can access the kubelet ports by default.

wget --no-check-certificate https://:1025

That will yield an Unauthorized response. If you try to use a client cert that is not in the system:masters organization you will get Forbidden as the return.

@joantune
Copy link

joantune commented Jul 19, 2017

That will yield an Unauthorized response. If you try to use a client cert that is not in the system:masters organization you will get Forbidden as the return.

🤔 I was pretty sure I got a 404 instead of a 401 from running that wget with an out of the box kubeadm 1.7.1 setup cluster. I guess I can always change the config, but it would be nice if kubeadm did it for us from the start perhaps (?)

@ericchiang
Copy link
Contributor

@joantune @luxas can you open issues against kubeadm for this? This issue is only to track the feature implemented in the kubelet.

@joantune
Copy link

joantune commented Jul 19, 2017

By the way, the documentation is ok detailing what are the concepts of Nodes, Pods and Clusters, and how they interact with each other, however, I found no reference on how these interact with the host's world, i.e. it would be nice to see some diagrams or similar on how the several services and concepts (pods, nodes, services, processes [i.e. kubectl, kubeproxy kubeadm]) interact with the host and its native network.

I have been looking quite thoroughly at the docs yet I have no clear picture of how that looks like in my head. Making it clearer would lower the barrier to learn it and use it.

Can anyone point me to a diagram/doc? I'm asking because I want to know exactly what should I expose or shouldn't network wise.

For instance, imagine that I have an equivalent to the Amazon's VPCs, what should be exposed to the outside what doesn't? how does a service get exposed? (i.e. is there any kubernetes process for which all the traffic flows through [e.g. kubeproxy] or does it expose the pod's port directly) would it be ok to have kubectl only accessible internally (if i'm willing to do an SSH tunnel to one of the machines). Would that still allow Kubernetes to work well?

These things would help sysadmins to have a clear picture if their network and cluster configuration are secure or not and confident that they are exposing the least they should

@davidopp
Copy link
Member

@joantune The best reference I've found for some of the questions you asked is this video:
https://www.youtube.com/watch?v=y2bhV81MfKQ

@fejta-bot
Copy link

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

Prevent issues from auto-closing with an /lifecycle frozen comment.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or @fejta.
/lifecycle stale

@k8s-ci-robot k8s-ci-robot added the lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. label Jan 1, 2018
@luxas
Copy link
Member

luxas commented Jan 1, 2018

keeping in beta status until the TokenReview and SubjectAccessReview APIs move to stable (now targeting 1.7)

@liggitt I'm pretty sure we can close this now as many deployments secure the kubelet API OOTB, and the APIs are v1/stable already.

@liggitt
Copy link
Member Author

liggitt commented Jan 2, 2018

@liggitt I'm pretty sure we can close this now as many deployments secure the kubelet API OOTB, and the APIs are v1/stable already.

agree, closing

@liggitt liggitt closed this as completed Jan 2, 2018
ingvagabund pushed a commit to ingvagabund/enhancements that referenced this issue Apr 2, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. sig/auth Categorizes an issue or PR as relevant to SIG Auth.
Projects
None yet
Development

No branches or pull requests