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

Change Container permissions to Private for provisioned Azure Volumes #47605

Merged
merged 1 commit into from Jun 16, 2017

Conversation

@brendandburns
Contributor

brendandburns commented Jun 15, 2017

@rootfs @philips #47611

Fixes CVE-2017-1002100

Azure: Change container permissions to private for provisioned volumes. If you have existing Azure volumes that were created by Kubernetes v1.6.0-v1.6.5, you should change the permissions on them manually.

@brendandburns brendandburns changed the title from Change Container permissions to Private. to Change Container permissions to Private for provisioned Azure Volumes Jun 15, 2017

@brendandburns

This comment has been minimized.

Contributor

brendandburns commented Jun 15, 2017

/approve no-issue

@rootfs

This comment has been minimized.

Member

rootfs commented Jun 15, 2017

/lgtm

@k8s-ci-robot k8s-ci-robot added the lgtm label Jun 15, 2017

@philips

This comment has been minimized.

Contributor

philips commented Jun 15, 2017

/lgtm

@jdumars

This comment has been minimized.

Member

jdumars commented Jun 15, 2017

/sig azure

@jdumars

This comment has been minimized.

Member

jdumars commented Jun 15, 2017

/retest

@jdumars

This comment has been minimized.

Member

jdumars commented Jun 15, 2017

/lgtm

@k8s-ci-robot

This comment has been minimized.

Contributor

k8s-ci-robot commented Jun 15, 2017

@jdumars: changing LGTM is restricted to assignees, and only kubernetes org members may be assigned issues.

In response to this:

/lgtm

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.

@brendandburns brendandburns added this to the v1.7 milestone Jun 15, 2017

@brendandburns

This comment has been minimized.

Contributor

brendandburns commented Jun 15, 2017

/approve no-issue

@brendandburns

This comment has been minimized.

Contributor

brendandburns commented Jun 15, 2017

/approve

@k8s-merge-robot

This comment has been minimized.

Contributor

k8s-merge-robot commented Jun 15, 2017

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: brendandburns, jdumars, philips, rootfs

Associated issue: 47611

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these OWNERS Files:

You can indicate your approval by writing /approve in a comment
You can cancel your approval by writing /approve cancel in a comment

@brendandburns

This comment has been minimized.

Contributor

brendandburns commented Jun 15, 2017

@k8s-bot pull-kubernetes-federation-e2e-gce test this

1 similar comment
@brendandburns

This comment has been minimized.

Contributor

brendandburns commented Jun 15, 2017

@k8s-bot pull-kubernetes-federation-e2e-gce test this

@seanknox

This comment has been minimized.

Member

seanknox commented Jun 15, 2017

/retest

@brendandburns

This comment has been minimized.

Contributor

brendandburns commented Jun 16, 2017

/retest

@brendandburns

This comment has been minimized.

Contributor

brendandburns commented Jun 16, 2017

Flakes were due to #47610

Retesting...

@k8s-merge-robot k8s-merge-robot removed the lgtm label Jun 16, 2017

@brendandburns brendandburns added the lgtm label Jun 16, 2017

@brendandburns

This comment has been minimized.

Contributor

brendandburns commented Jun 16, 2017

self-lgtm since this was just a rebase.

@brendandburns

This comment has been minimized.

Contributor

brendandburns commented Jun 16, 2017

@k8s-bot pull-kubernetes-e2e-gce-etcd3 test this

@k8s-merge-robot

This comment has been minimized.

Contributor

k8s-merge-robot commented Jun 16, 2017

Automatic merge from submit-queue (batch tested with PRs 47562, 47605)

@k8s-merge-robot k8s-merge-robot merged commit 7831a54 into kubernetes:master Jun 16, 2017

10 checks passed

Submit Queue Queued to run github e2e tests a second time.
Details
cla/linuxfoundation brendandburns authorized
Details
pull-kubernetes-bazel Job succeeded.
Details
pull-kubernetes-e2e-gce-etcd3 Jenkins job succeeded.
Details
pull-kubernetes-e2e-kops-aws Jenkins job succeeded.
Details
pull-kubernetes-federation-e2e-gce Jenkins job succeeded.
Details
pull-kubernetes-kubemark-e2e-gce Jenkins job succeeded.
Details
pull-kubernetes-node-e2e Jenkins job succeeded.
Details
pull-kubernetes-unit Jenkins job succeeded.
Details
pull-kubernetes-verify Jenkins job succeeded.
Details

k8s-merge-robot added a commit that referenced this pull request Jun 16, 2017

Merge pull request #47630 from brendandburns/automated-cherry-pick-of-#…
…47605-upstream-release-1.6

Automatic merge from submit-queue

Automated cherry-pick of #47605

@enisoc @philips 

See #47605
@philips

This comment has been minimized.

Contributor

philips commented Jun 16, 2017

This fixes a security issue, see the release notes here: https://groups.google.com/forum/#!topic/kubernetes-announce/WodXsASu6y0

A vulnerability has been disclosed in which default access permissions for Persistent Volumes (PVs) created by the Kubernetes Azure cloud provider in versions 1.6.0 to 1.6.5 are set to "container" which exposes a URI that can be accessed without authentication on the public internet. Access to the URI string requires privileged access to the Kubernetes cluster or authenticated access to the Azure portal.

The vulnerability is tracked in http://issue.k8s.io/47611, and fixed in release v1.6.6, available immediately. The fix is also included in the upcoming 1.7.0 release.

Who is affected?

Only Kubernetes 1.6.0-1.6.5 installations that have Persistent Volumes (PVs) actively provisioned through the Azure cloud provider are subject to the vulnerability. Clusters without PVs are unaffected. No other form of cluster storage is impacted.

What is the impact?

An individual with the full URI of an actively provisioned persistent volume can download the VHD file for that volume. It does not apply retroactively to volumes already deleted from the cluster.

How can I mitigate this prior to installing 1.6.6?

Permissions on running persistent volumes can be changed without affecting cluster operations using the Azure CLI or through the Azure web portal. A full procedure for both methods is available here: https://aka.ms/f5tslk

Azure Container Service rollout of 1.6.6 will begin immediately.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment