<p>Recently critical vulnerability is found in kubernetes where hackers can send authorized message and acces the kubernetes and from there try to login to back-end.
Is this possible only in  public or as well as private network?  How? </p>

Solomon
<p>The <strong>key point</strong> here is:</p>

<blockquote>
  <p>In all Kubernetes versions prior to v1.10.11, v1.11.5, and v1.12.3.</p>
</blockquote>

<p>These applies to old <strong>Kubernetes</strong> versions which are not supported any more and you are not supposed to use them on production systems. If you want to familiarize with Kubernetes version support policy, please refer to <a href="https://kubernetes.io/docs/setup/release/version-skew-policy/" rel="nofollow noreferrer">this</a> article. As you can read in it:</p>

<blockquote>
  <p>The Kubernetes project maintains release branches for the most recent
  three minor releases. Applicable fixes, including security fixes, may
  be backported to those three release branches, depending on severity
  and feasibility.</p>
</blockquote>

<p>Currently they are: 1.13, 1.14 and 1.15 versions.</p>

<p>As you can see <a href="https://nvd.nist.gov/vuln/detail/CVE-2018-1002105" rel="nofollow noreferrer">here</a> or <a href="https://www.twistlock.com/labs-blog/demystifying-kubernetes-cve-2018-1002105-dead-simple-exploit/" rel="nofollow noreferrer">here</a> the vulnerability was made public in December 2018  so I wouldn't say that in terms of contemporary software development process standards it is <em>recently</em>. It doesn't make sense to deliberate if its safe or not to use some software with vulnerabilities/bugs which are already fixed in newer versions, available from a long time.</p>

<p>If you are interested in this bug, you can analyze <a href="https://github.com/kubernetes/kubernetes/issues/71411" rel="nofollow noreferrer">this</a> GitHub issue or read a nice description of it in <a href="https://www.twistlock.com/labs-blog/demystifying-kubernetes-cve-2018-1002105-dead-simple-exploit/" rel="nofollow noreferrer">this</a> article. As you can read:</p>

<blockquote>
  <p>The bug allows an attacker who can send a legitimate, authorized
  request to the API server to bypass the authorization logic in any
  sequenced request. In other words, escalate privileges to that of any
  user.</p>
</blockquote>

<p><strong>In other words:</strong> to be able to bypass the authorization logic in subsequent requests or to escalate privileges, such user needs to be able to send legitimate, authorized requests to the API server. </p>

<p>So at this point you can probably answer your question yourself. The key point isn't the fact that the network is public or private. More important is how it is secured and by whom it can be accessed. Generally private networks with no external access (e.g. intranets) tend to be more secure but if it comes to things like possible privilege escalation by someone who already has some level of access, it is potentially dangerous even within organization.</p>
