One Article Review
| Source |  AlienVault Blog |
|---|---|
| Identifiant | 2188855 |
| Date de publication | 2021-01-14 11:00:00 (vue: 2021-01-14 11:05:28) |
| Titre | Security context: The starting point for how Kubernetes Pod security works |
| Texte | This blog was written by an independent guest blogger. Organizations are increasingly adopting Kubernetes to manage their containerized workloads and services, but Kubernetes security incidents are on the rise, as well. In the fall 2020 edition of the “State of Container and Kubernetes Security” report, for instance, 91% of respondents told StackRox that they had recently adopted Kubernetes. Three quarters of survey participants went on to reveal that they had deployed the container orchestration platform in their production environments. Even so, nine out of 10 respondents told the company that their organizations had suffered a security incident in their container and Kubernetes environments over the last 12 months. Subsequently, nearly half (44%) of respondents said that they had delayed moving an application into production due to their security concerns. These findings highlight the need for organizations to strengthen their Kubernetes security. They can do this by focusing on the security of their pods. StackRox explains why in a blog post: Securing pods, and the containers that run as part of them, is a critical aspect of protecting your Kubernetes environments. Among other reasons, pods and containers are the individual units of compute that are ultimately subject to adversarial techniques that may be used as part of any attack on your Kubernetes clusters. Since pods are also the smallest resource you can deploy and manage in Kubernetes, applying security at this level ensures greater fine-grained controls that are scoped to individual application components. Organizations can specifically use Pod Security Policies (PSPs) to strengthen their pod security. Before that even happens, they need to figure out what they want to define within those PSPs. That’s where security context comes into play. What are security contexts? According to Kubernetes’ documentation, security contexts define the privileges and access control settings for a selected pod or container. These settings include Linux Capabilities through which users can specify whether to give a process some privileges but not those of a root user. They also include AllowPrivilegeEscalation, or controls through which users can make a process more privileged than its parent process. Additional examples of security contexts are available here. To set up security contexts, users need to have a Kubernetes cluster and the kubectl command-line tool configured to communicate with that cluster. They can then include the “securityContext” field in the specification for their pod or container. This action applies whatever security settings they want to their selected resource. Moving on with Pod Security Policies Once they know the security context, organizations can create a Pod Security Policy. Kubernetes notes elsewhere on its website that a PSP functions as a cluster-level resource that defines the security conditions under which a pod is allowed to run. Such a policy encapsulates and enforces one or more security contexts chosen by the user. |
| Envoyé | Oui |
| Condensat | “state 2020 able about absence access according account across action active add additional admission adopted adopting adversarial allow allowed allowing allowprivilegeescalation along also among another any application applications applies applying apps architecture are aspect attack attackers authorize available based baseline/default: before best beyond bit blog blogger broadly build but can can’t capabilities charged choose chosen cluster clusters comes command communicate company compatibility components compute conceived concerns conditions configurations configured constraints contain container containerized containers context context: contexts control controller controlling controls create critical define defines delayed deploy deployed determines developers development different documentation doesn’t don’t due edition elsewhere enable encapsulates end enforce enforces ensures environment environments escalation even examples existing explains fall feature field figure findings fine first focusing follows: foremost functions give govern grained greater guest had half happens harden hardening have help here highlight how incident incidents include increasingly independent individual infrastructure instance its itself just kinds know kubectl kubernetes kubernetes’ last laterally learn level limit limited line linux look lower make manage managing may minimize months more most moving nearly need next nine non not notes occurrence once one only operators orchestration organizations other out over overall own parent part participants phases platform play pod pod’s pods point policies policy possibility post: practices privilege privileged privileged: privileges process production proper protecting psp psps quarters rather reasons recently regard report resource respondents restricted restricted: restrictions reveal rise root run runtime sacrifice said scoped secure securing security security” selected sense serve service services set settings should since smallest solution’s some specific specifically specification specify stackrox standalone starting stop strengthen subject subsequently such suffered suited survey system techniques than that’s them then these those three through told tool trust types ultimately under units unrestricted upon use used user users using verb viewing want way ways website well went what whatever where whether which who why within work workloads works written your |
| Tags | |
| 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.