Cannot upgrade to the latest Kubernetes orchestrator using the latest acs-engine (0.26.0)

orlandoalexandrescu commented 5 years ago

Is this a request for help?: NO

Is this an ISSUE or FEATURE REQUEST? (choose one): ISSUE

What version of acs-engine?: 0.26.0

Orchestrator and version (e.g. Kubernetes, DC/OS, Swarm) Kubernetes 1.10.2

What happened: I cannot upgrade our acs-engine deployed clusters to version 1.10.11.

What you expected to happen: If I run

acs-engine orchestrators --orchestrator Kubernetes --version 1.10.2

I should get either "1.10.11" or "1.11.5", both not appearing in the above upgrade path.

How to reproduce it (as minimally and precisely as possible):

If I run

acs-engine orchestrators --orchestrator Kubernetes --version 1.10.2

I get:

{
  "orchestrators": [
    {
      "orchestratorType": "Kubernetes",
      "orchestratorVersion": "1.10.2",
      "upgrades": [
        {
          "orchestratorType": "",
          "orchestratorVersion": "1.10.8"
        },
        {
          "orchestratorType": "",
          "orchestratorVersion": "1.10.9"
        },
        {
          "orchestratorType": "",
          "orchestratorVersion": "1.11.3"
        },
        {
          "orchestratorType": "",
          "orchestratorVersion": "1.11.4"
        }
      ]
    }
  ]
}

Anything else we need to know:

Following this security vulnerability discovery, we need to upgrade our clusters to the latest version.

https://groups.google.com/forum/#!topic/kubernetes-announce/GVllWCg6L88

https://github.com/kubernetes/kubernetes/issues/71411

Michael-Sinz commented 5 years ago

We have the same issue - we need to get to 1.10.11 in our clusters.

pascalgn commented 5 years ago

Depending on your threat model

The second method lets an unauthenticated user access the API to create unapproved services (https://github.com/kubernetes/kubernetes/issues/71411)

might be the much more important issue at the moment (it is for us).

Mitigations for the anonymous user -> aggregated API server escalation include: disable anonymous requests by passing --anonymous-auth=false to the kube-apiserver (note that this may disrupt load balancer or kubelet health checks of the kube-apiserver, and breaks kubeadm join setup flows)

However, at least when using acs-engine, this already seems to be the default: --anonymous-auth=false (see docs/clusterdefinition.md)

So from my understanding, anonymous access will not be possible when setting up a cluster with acs-engine (provided default options are used). The other issues of CVE-2018-1002105 are unaffected from this, though!

CecileRobertMichon commented 5 years ago

@pascalgn is correct, acs-engine clusters have --anonymous-auth=false which means they are not affected (that value is not user-configurable).

That being said, we will have a patch release containing 1.11.5 coming shortly (ETA today).

CecileRobertMichon commented 5 years ago

https://github.com/Azure/acs-engine/releases/tag/v0.26.1

Azure / acs-engine