One Article Review
| Source |  AlienVault Blog |
|---|---|
| Identifiant | 1985636 |
| Date de publication | 2020-10-19 11:00:00 (vue: 2020-10-19 12:05:50) |
| Titre | PSPs vs. OPA Gatekeeper: Breaking down your Kubernetes Pod security options |
| Texte | This blog was written by an independent guest blogger. Organizations are increasingly turning to Kubernetes, but they’re having trouble balancing security in the process. In its State of Container and Kubernetes Security Fall 2020 survey, for instance, StackRox found that 91% of respondents were using Kubernetes to orchestrate their containers and that three quarters of organizations were using the open-source container-orchestration system in production. Even so, nine in 10 respondents told StackRox in its poll that they had experienced a security event in their container and Kubernetes environment in the last 12 months. Two-thirds of organizations said those incidents had involved a misconfiguration. These findings highlight the need for organizations to enhance the security of their Kubernetes environments against misconfiguration incidents. In this blog post, we’ll narrow our focus and discuss how one type of misconfiguration in particular—embracing default pod communication—endangers organizations’ security. We’ll then discuss how organizations can use either Pod Security Policies (PSPs) or OPA Gatekeeper to ensure the security of their pods. Understanding the Security Challenges of Pod Communication To understand the security challenges inherent in default Kubernetes pod communication, it’s important that we first define what a pod is and does. Pods consist of one or more containers, shared storage/network resources and specifications for running those containers, according to the Kubernetes website. When framed in Docker terms, pods act as groups of Docker containers that share namespaces and filesystem volumes. These small computing units help organizations to group containers together and have these resources collaborate on specific projects or sets of work. Where organizations run into challenges is the way in which pods communicate by default. As noted elsewhere on Kubernetes website, the standard configuration for pods is non-isolated in that they are capable of accepting traffic from any source. This is a problem, as this type of open communication potentially enables malicious actors to abuse the Kubernetes environment for nefarious purposes. Digital attackers could stage an attack in which they create a malicious container and use that to compromise its corresponding pod, for instance. That actor could then abuse unrestricted communication between pods to move laterally throughout the Kubernetes environment, deploying cryptominers and installing infostealing malware along the way. Using Security Context to Address These Challenges Fortunately, organizations can address these security challenges associated with pods using what are known as security contexts. Kubernetes notes on its site that security contexts function as configurations that help to define the security properties of a pod or a container. These configurations include access controls that govern who can access a pod or container and whether a Kubernetes resource is privileged. With the right security contexts, organizations can therefore prevent unauthorized actors from gaining access to a container, from elevating privileges on a compromised resource and from moving laterally on the network. Enforcing Security Context with Pod Security Policies When it comes time to enforce a security context, organizations may choose to use pod security policies (PSPs). These cluster-level resources manage the specifications under which a pod is allowed to run on a s |
| Envoyé | Oui |
| Condensat | “hardening 2020 ability abuse accepting access according account across act actor actors added address addressing administrators admission advantage after against agent all allowed allowing along alphabetical also always amazon among any anything applies are associated attack attackers authorize authorizing automate automating availability aws balancing based been before best beta between bit blog blogger breaking but can capable challenges choose cluster clusters collaborate come comes commits communicate communication communication—endangers complex compliance complies compromise compromised computing concerns configuration configurations consider consist container containers context contexts control controller controls corresponding could cover create creating cryptominers cumbersome; custom default define defined defining deploying design detect digital discuss docker does don’t down drawbacks easy either elevating elsewhere empower enable enables enabling enforce enforcement enforcing engine enhance ensure environment environments especially essence essentially even event experienced explained extensible fall file filesystem findings first focus fortunately found framed from function functions gaining gatekeeper gatekeeper: general get govern group groups guarantee guest had have having help here highlight how images implementing important inadvertently incidents include increasingly independent infostealing inherent inside installing instance instead involved isn’t isolated it’s its known kubernetes kubernetes’ last laterally level limitations limits listed look make makes malicious malware manage manually many may means might misconfiguration monitor months more move moving namespaces narrow native need nefarious network nine non noncompliant not noted notes now one only opa open operate opting options orchestrate orchestration order organization organizations organizations’ other own particular—embracing pod pod’s pods policies policy poll portable post potentially practices prevent privileged privileges problem process production projects properties protect psps psps’ purpose purposes quarters quite rbac resource resources respondents responding reversed right role run running said same save scale security service sets share shared shortcomings should site slow small solutions some sometimes source spawning specific specifications specify specs stackrox stage standard state storage/network survey system target teams terms than that’s them then there’s therefore these they’ll they’re they’ve things thirds those three through throughout time time; times together told top traffic trouble turning two type unauthorized under understand understanding units unrestricted updated uphold use used user using verb volumes way we’ll webhook website what when where whether which who why will without work written your |
| Tags | Malware |
| 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.