Bug 1730161 (CVE-2019-10200) - CVE-2019-10200 openshift: Users with permission to schedule pods on master nodes can access credentials for AWS IAM roles
Summary: CVE-2019-10200 openshift: Users with permission to schedule pods on master no...
Keywords:
Status: CLOSED ERRATA
Alias: CVE-2019-10200
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Red Hat Product Security
QA Contact:
URL:
Whiteboard:
Depends On: 1729242 1730165 1782646 1782647
Blocks: 1729923 1940792
TreeView+ depends on / blocked
 
Reported: 2019-07-16 02:59 UTC by Sam Fowler
Modified: 2021-10-25 09:52 UTC (History)
19 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
A flaw was discovered in OpenShift Container Platform 4 where, by default, users with access to create pods also have the ability to schedule workloads on master nodes. Pods with permission to access the host network, running on master nodes, can retrieve security credentials for the master AWS IAM role, allowing management access to AWS resources. With access to the security credentials, the user then has access to the entire infrastructure. Impact to data and system availability is high.
Clone Of:
Environment:
Last Closed: 2021-10-25 09:52:58 UTC
Embargoed:


Attachments (Terms of Use)

Description Sam Fowler 2019-07-16 02:59:38 UTC
In the default configuration, OpenShift Container Platform 4 allows users with access to create pods the ability to schedule workloads on master nodes. Pods with permission to access the host network, running on master nodes, can retrieve security credentials for the master AWS IAM role, allowing management access to AWS resources. Pod access to the host network can be granted with the hostnetwork SCC.


Original Bug:

https://bugzilla.redhat.com/show_bug.cgi?id=1729242


Upstream Fix:

https://github.com/openshift/cluster-kube-apiserver-operator/pull/524

Comment 4 Sam Fowler 2019-12-12 03:47:45 UTC
OpenShift Documentation has been updated to include the following:

"If additional workloads are run on master hosts, use caution when providing access to hostnetwork. A workload that runs hostnetwork on a master host is effectively root on the cluster and must be trusted accordingly."

https://docs.openshift.com/container-platform/4.1/authentication/managing-security-context-constraints.html

Comment 5 Sam Fowler 2019-12-12 04:54:46 UTC
Transitioning to Version 2 of the Instance Metadata Service would address this issue:

https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/configuring-instance-metadata-service.html

Comment 6 Sam Fowler 2020-05-06 05:59:33 UTC
In reply to comment #5:
> Transitioning to Version 2 of the Instance Metadata Service would address
> this issue:
> 
> https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/configuring-instance-
> metadata-service.html

While IMDSv2 seems a valuable defense-in-depth measure (to protect against SSRF etc), it seems a pod with access to the host network on a master node will still be able to retrieve IAM role credentials (via an additional PUT request beforehand).

Comment 9 Sam Fowler 2020-05-20 02:13:15 UTC
Downgrading impact to Moderate as only admin users should be able to schedule pods onto master nodes.

Comment 13 Sam Fowler 2020-08-20 02:18:01 UTC
Mitigation:

Do not run untrusted workloads with `hostnetwork` access on master nodes.

If additional workloads are run on master hosts, use caution when providing access to hostnetwork. A workload that runs hostnetwork on a master host is effectively root on the cluster and must be trusted accordingly.


https://docs.openshift.com/container-platform/4.4/authentication/managing-security-context-constraints.html


Note You need to log in before you can comment on or make changes to this bug.