Bug 1730161 (CVE-2019-10200)
Summary: | CVE-2019-10200 openshift: Users with permission to schedule pods on master nodes can access credentials for AWS IAM roles | ||
---|---|---|---|
Product: | [Other] Security Response | Reporter: | Sam Fowler <sfowler> |
Component: | vulnerability | Assignee: | Red Hat Product Security <security-response-team> |
Status: | CLOSED ERRATA | QA Contact: | |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | unspecified | CC: | ahardin, aos-bugs, bleanhar, bmontgom, ccoleman, cscribne, dahernan, dedgar, dominik.mierzejewski, eparis, jburrell, jgoulding, jokerman, mchappel, mfojtik, nstielau, sfowler, sponnaga, sttts |
Target Milestone: | --- | Keywords: | Security |
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
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.
|
Story Points: | --- |
Clone Of: | Environment: | ||
Last Closed: | 2021-10-25 09:52:58 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: | |||
Bug Depends On: | 1729242, 1730165, 1782646, 1782647 | ||
Bug Blocks: | 1729923, 1940792 |
Description
Sam Fowler
2019-07-16 02:59:38 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 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 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). Downgrading impact to Moderate as only admin users should be able to schedule pods onto master nodes. 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 |