One Article Review
| Source |  AlienVault Blog |
|---|---|
| Identifiant | 2329673 |
| Date de publication | 2021-02-11 11:00:00 (vue: 2021-02-11 12:05:24) |
| Titre | The Kubernetes API Server: Exploring its security impact and how to lock it down |
| Texte | This blog was written by an independent guest blogger. Organizations are increasingly turning to Kubernetes to manage their containers. As reported by Container Journal, 48% of respondents to a 2020 survey said that their organizations were using the platform. That’s up from 27% two years prior. These organizations could be turning to Kubernetes for the many benefits it affords them. As noted in its documentation, Kubernetes comes with the ability to distribute the container network traffic so as to keep organizations’ applications up and running. The platform is also capable of moving the actual state of any deployed containers to a desired state specified by the user as well of replacing and killing containers that don’t respond to a health check. The double-edged growth of Kubernetes clusters The benefits mentioned above trace back to the advantage of the Kubernetes cluster. At a minimum, a cluster consists of a control plane for maintaining the cluster’s desired state and a set of nodes for running the applications and workloads. Clusters make it possible for organizations to run containers across a group of machines in their environment. There’s just one problem: the number of clusters under organizations’ management is on the rise. This growth in clusters creates network complexity that complicates the task of securing a Kubernetes environment. As StackRox explains in a blog post: That’s because in a sprawling Kubernetes environment with several clusters spanning tens, hundreds, or even thousands of nodes, created by hundreds of different developers, manually checking the configurations is not feasible. And like all humans, developers can make mistakes – especially given that Kubernetes configuration options are complicated, security features are not enabled by default, and most of the community is learning how to effectively use components including Pod Security Policies and Security Context, Network Policies, RBAC, the API server, kubelet, and other Kubernetes controls. The last thing that organizations want to do is enable a malicious actor to authorize their Kubernetes environment. This raises an important question: how can organizations make sure they’re taking the necessary security precautions? Look to the Kubernetes API Server Organizations can help strengthen the security of their Kubernetes environment by locking down the Kubernetes API server. Also known as kube-apiserver, the Kubernetes API server is the frontend of the control plane that exposes the Kubernetes API. This element is responsible for helping end users, different parts of the cluster and external elements communicate with one another. A compromise of the API server could enable attackers to manipulate the communication between different Kubernetes components. This could include having them communicate with malicious resources that are hosted externally. Additionally, they could leverage this communication channel to spread malware like cryptominers amongst all the pods, activity which could threaten the availability of the organization’s applications and services. Fortunately, organizations can take several steps to secure the Kubernetes API server. Presented below are a few recommendations. Stay on top of Kubernetes updates From time to time, Kubernetes releases a software update that patches a vulnerability affecting the Kubernetes API server. It’s important that administrators implement those fixes on a timely basis. Otherwise, they could give malici |
| Envoyé | Oui |
| Condensat | 2020 443 ability above accept access across active activity actor actors actual additionally administrators advantage affecting affords all allow along also always amongst anonymous another any api apiserver applications are argument attackers auth authenticate authentication authority authorization authorize availability back basic basis because below benefits between blog blogger can capable certificate certificate’s certificates channel check checking client clients cluster cluster’s clusters comes command commands communicate communication community complexity complicated complicates components compromise confidentiality configuration configurations configure configured confirm connections consists container containers context control controls copy could created creates credentials cryptominers default deployed desired determines developers different disallow distribute documentation does doesn’t doing don’t double down edged effectively element elements enable enabled encrypted end ensure environment especially even explains exploit exploring exposes external externally false feasible features file find fixes follow fortunately from frontend gain give given group growth guarantee guest harden have having health help helping here hosted how https humans hundreds impact implement important include including increasingly independent insecure instead intentionally isn’t it’s its journal just keep killing known kube kube/config kubelet kubelets kubernetes last latter layer learning leverage like lines linked lock locking look machines maintaining make malformed malicious malware manage management manipulate manually many mentioned method minimum mistakes more most moving necessary need network nodes not noted number one opportunity option options order organization’s organizations organizations’ other otherwise part particular: parts patches permissions plaintext plane platform platform’s pod pods policies port possible post: precautions presented presents prior private problem: protected protection question: raises rbac recommendations reject releases repair replacing reported requests resources respond respondents responsible result rise run running said same secure securing security see series server server: serves services set several shows software spanning specified sprawling spread stackrox state stay step steps strengthen sure survey take taking task tens testify that’s them there’s these they’re thing those thousands threaten time timely tls token tokens top trace traffic transit transport true turning two types typical under update updates use useful user users uses using verify vulnerability want weaknesses well when which who will workloads written years |
| Tags | Malware 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.