One Article Review
| Source |  AlienVault Blog |
|---|---|
| Identifiant | 2071824 |
| Date de publication | 2020-12-02 12:00:00 (vue: 2020-12-02 12:05:28) |
| Titre | How to secure a Kubernetes cluster |
| Texte | This blog was written by an independent guest blogger. More and more organizations are adopting Kubernetes, but they’re encountering security challenges along the way. In the fall 2020 edition of its “State of Container and Kubernetes Security” report, for instance, StackRox found that nearly 91% of surveyed organizations had adopted Kubernetes, with a majority (75%) of participants revealing that they had deployed the container orchestration platform into their production environments. Even so, nine in 10 respondents said that they had experienced a security incident involving a misconfiguration, vulnerability or runtime error in their container and Kubernetes environments over the last 12 months. Nearly half (44%) went on to say that they had delayed moving an application into production as a result of their security concerns. These findings highlight the need for organizations to ensure their Kubernetes configurations complement their security requirements. As part of this process, administrators can focus in on protecting their clusters, which are part of the Kubernetes architecture. After defining what a cluster is, this blog post will explore the two sets of components that exist within a cluster and provide guidance on how organizations can secure those components along the way. Understanding the Kubernetes cluster On its website, Kubernetes says that customers get a cluster—or a set of one or more worker machines called “nodes” that are responsible for running a containerized application—whenever they deploy Kubernetes. These nodes host pods, groups of one or more containers which function as the application workload’s components. Ultimately, Kubernetes makes it possible for administrators to manage the nodes and the cluster more generally, including events that affect either, by using the control plane. Administrators can secure a Kubernetes cluster by specifically directing their efforts to the control plane and the worker nodes. The control plane Within the control plane, administrators can focus their security measures on five components: kube-apiserver, etcd, kube-scheduler, kube-controller-manager and cloud-controller-manager. kube-apiserver The kube-apiserver is the main implementation of a Kubernetes API server within a Kubernetes deployment. It scales horizontally as administrators deploy more instances of kube-apiserver to balance traffic within their environments. As the front end for the Kubernetes control plane, the API server potentially exposes the Kubernetes API. Administrators can secure this element by upgrading to the newest version of Kubernetes and by applying updates, thereby closing security gaps. From there, administrators can restrict access to the Kubernetes API server by setting up authentication for Kubernetes API clients and ensuring all API traffic is encrypted using TLS. etcd A key value store, etcd functions as the backing store for all Kubernetes cluster data. Administrators might want to consider having a back-up plan for that data. Similar to the kube-apiserver, they can once again turn to encryption, authentication and access control as a means of gaining visibility over read and write access to that data store. kube-scheduler Within the control plane, administrators can use the kube-scheduler component to function for newly created pods that don’t have an a |
| Envoyé | Oui |
| Condensat | “ensure “state 2020 above access account add addition administrators adopted adopting affect after again all allowing along also api apiserver application application—whenever apply applying architecture are assign assigned authentication authorization available back backing balance based bind blog blogger broadly but called can challenges clients closing cloud cluster cluster—or clusters communication complement component components components: concerns configurations configure configured conjunction consider constraints container containerized containers containers’ control controller controllers correct created credential customers data defining delayed depending deploy deployed deployment directing disallowing discussion docker documentation doesn’t don’t down; each edition efforts either element enables encountering encrypted encryption end enforces ensure ensures ensuring environments error etcd even events exist experienced explore exposes facilitate factors fall feature features file findings five focus follow following found from front function functions further gaining gaps generally get goes groups guest guidance guidelines had half have having highlight horizontally host how however https identified implement implementation important inception incident includes including independent individual information inside instance instances interface involving it’s its key kube kubeconfig kubelet kubernetes kubernetes’ last launched least like limit link lives localhost locality looking loops machines main majority make makes manage manager means measures might minimum misconfiguration months more moving name nearly need network newest newly nine node node: nodes not note number once one only ons optimally optimize orchestration organizations other outside over part participants parts patches per permissions plan plane platform pod pods policy port possible post potentially privileges process processes production protected protecting provide provider provider’s provides proxy rbac read recommends remediate replication report required requirements resource resources respondents responds responsible restrict restricting result revealing reviewing rules run running runs runtime runtimes said same say says scales scheduler secure secured securing security security” serve server service services set sets setting similar software specific specifically specifications ssh stackrox step store strong support sure surveyed system; that’s then there’s thereby these they’re those three time tls traffic turn two ultimately understanding updates upgrading use used using value various version visibility vulnerabilities vulnerability want way website well went what when which who will within worker workload’s write written |
| Tags | Vulnerability |
| Stories | Uber |
| Notes | |
| Move | 
|
L'article ne semble pas avoir été repris aprés sa publication.
L'article ne semble pas avoir été repris sur un précédent.