k8s just announced a major vulnerability in versions prior to 1.10.11, the recommended version from kops is currently 1.10.6.
Just for completeness: the recommented version in kops is in https://github.com/kubernetes/kops/blob/be291eea86440db964800e07828068f5725fbaf3/channels/stable . We upgraded (with kops) to 1.10.11 in one of our clusters and we haven't seen any problem yet.
How can I upgrade existing cluster made by kops?
My kops ver. is 1.10.0 now, so I guess I should upgrade it.
Also note that kops has disabled anonymous-authentication on kube-apiserver since its introduction, which should reduce the scope of the vulnerability (I believe this means that it can only be exploited by authenticated users): https://github.com/kubernetes/kops/blob/master/pkg/model/components/apiserver.go#L274-L277
I version the cluster YAML and replace the version there, you need to have kubernetesVersion: 1.10.11. Not sure if there are any issues there, but I have some clusters running now with 1.10.11 and so far so good.
As @justinsb said above, if you didn't customize the setting for the API server, the exploit cannot be exploited by external unauthenticated users, so it reduces the vulnerability a lot.
Looking at the issue referenced in the description (kubernetes/kubernetes#71411) it says:
An API call to any aggregated API server endpoint can be escalated to perform any API request against that aggregated API server, as long as that aggregated API server is directly accessible from the Kubernetes API server鈥檚 network. In default configurations, all users (authenticated and unauthenticated) are allowed to perform discovery API calls that allow this escalation.
So it would seem that if you are using "default configurations" then unauthenticated users _can_ exploit this vulnerability.
I believe the permissions they are referring to are the ones granted by the default system:discovery ClusterRole and ClusterRoleBinding
Good write up here by Rancher
https://rancher.com/blog/2018/2018-12-04-k8s-cve/
The issue has been resolved in #6158
What is the version that we should update to so that it avoids the bug and is supported by kops ?
Thank you.
Just in case anyone needs it:
Upgrade gist https://gist.github.com/vfarcic/763c38b562c9b857ccfd10459c8e5ea9
@savicprvoslav You can see it in the PR: kubernetesVersion: 1.10.11 in case you are with kubernetes 1.10.
@asmith60 FYI, kops is not running the default configuration - it disallows anonymous authentication to the apiserver entirely. So we should be a little bit less vulnerable than other configurations.
That said, everyone should update to 1.10.11.
We're also taking the opportunity to review the general security position of kops, aiming to run the most secure configuration available (https://github.com/kubernetes/kops/issues/6150). (And I should say we're aiming for equal first place, not competitive - ideally all tooling will be secure by default!)
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.
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
Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.
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 rotten
Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.
Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/close
@fejta-bot: Closing this issue.
In response to this:
Rotten issues close after 30d of inactivity.
Reopen the issue with/reopen.
Mark the issue as fresh with/remove-lifecycle rotten.Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/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.
Most helpful comment
Also note that kops has disabled anonymous-authentication on kube-apiserver since its introduction, which should reduce the scope of the vulnerability (I believe this means that it can only be exploited by authenticated users): https://github.com/kubernetes/kops/blob/master/pkg/model/components/apiserver.go#L274-L277