Scribd
Upload
18 views3 pages

Task 1

The document discusses Kubernetes role-based access control (RBAC) configuration and common mistakes made in RBAC configuration. It also discusses the differences between container and virtual machine security, noting that containers share resources and require controls on connections between containers and restricting container privileges. The document outlines best practices for container runtime configuration in Kubernetes through security contexts, pod security policies, and admission controllers.

Uploaded by

palledeekshitha704
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as TXT, PDF, TXT or read online on Scribd
18 views3 pages

Task 1

The document discusses Kubernetes role-based access control (RBAC) configuration and common mistakes made in RBAC configuration. It also discusses the differences between container and virtual machine security, noting that containers share resources and require controls on connections between containers and restricting container privileges. The document outlines best practices for container runtime configuration in Kubernetes through security contexts, pod security policies, and admission controllers.

Uploaded by

palledeekshitha704
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as TXT, PDF, TXT or read online on Scribd
You are on page 1/ 3

notes of task1

Configuring Kubernetes Role-Based Access Control (RBAC):

Your cluster’s RBAC configuration controls which subjects can execute which verbs
on which resource types in which namespaces.The RBAC API includes four declarative
objects: Role, ClusterRole, RoleBinding, and ClusterRoleBinding.

Roles are a namespaced-resource consisting of rules that set permissions for


individual namespaces, whereas ClusterRoles are non-namespaced-resource that grant
clusterwide permissions or permissions that span multiple namespaces. Each rule is
a combination of verbs, resource types, and namespace selectors.

A role binding is the bridge that ties a user, group of users, or a service account
(also known as subjects) to a role and grants those users the permissions defined
in that role. A cluster role binding ties a ClusterRole to all the namespaces in
your cluster. In this way, a RoleBinding assigns permissions within a namespace,
whereas a ClusterRoleBinding grants those permissions clusterwide.

Configuration mistake 1:Cluster administrator role granted unnecessarily

Configuration mistake 2:Improper use of role aggregation

Configuration mistake 3:Duplicated role grant

Configuration mistake 4:Unused role

Configuration mistake 5:Grant of missing roles

Container and Kubernetes vs. Virtual Machine (VM) security

Virtual machines (VMs) and containers have fundamentally different architectures,


though they have just enough similarities to cause some confusion. The differences
between containers and VMs have very important security ramifications. Both VMs and
containers provide isolation to varying degrees, and both enable portability.
Virtual machines are completely self-sufficient, have their own operating system,
and do not share resources with other virtual machines. Containers share hosts with
other containers, complicating the idea of a secure boundary.

Securing containers requires:

Controlling connections between containers


Ensuring containers are free of known vulnerabilities
Preventing containers from having root access
Restricting permissions and access to only what’s needed for the application to
function

Security in containerized applications requires controlling the source of all


components including open source elements, managing configurations, scanning
images, and enabling granular role-based access controls. Containers and Kubernetes
force a different approach to security, but given their declarative and immutable
nature, they do present the opportunity—when properly configured—to build the most
secure applications ever created.
Container runtime configuration
In Kubernetes, containers run inside pods, one of several Kubernetes Objects, and
each Pod’s runtime configuration can be set and enforced using a combination of
security context in the Pod specification, Pod Security Policies (PSPs), or an
admission controller like the Open Policy Agent (OPA) Gatekeeper.

It can be configured for a Pod or Container. Pod Security Policies are a cluster-
level Kubernetes resource that control the security context Pods can run with. If
PSPs are enabled for a cluster, any attempt to create a Pod which does not adhere
to its associated PSP will be rejected by the PSP admission controller.

Limit container runtime privileges:

Do not run application processes as root. Set runAsUser to MustRunAsNonRoot


Do not allow privilege escalation. Set allowPrivilegeEscalation to false
Use a read-only root filesystem. Set readOnlyRootFilesystem to true
Use the default (masked) /proc filesystem mount
Do not use the host network or process space. Set hostPID, hostNetwork, and hostIPC
to false
Drop unused Linux capabilities and do not add optional capabilities that your
application does not absolutely require
Use SELinux options for more fine-grained process controls
Give each application its own Kubernetes Service Account
Do not mount the service account credentials in a container if it does not need to
access the Kubernetes API

Use Kubernetes namespaces

Kubernetes namespaces provide scoping for cluster objects, allowing fine-grained


cluster object management. Containers/Pods, services, and deployments within a
namespace can be isolated using controls like Kubernetes network policies or have
their access restricted using Kubernetes Role-Based Access Control (RBAC).

Kubernetes configuration management

The cornerstones of configuration management for containers and Kubernetes are the
following:

Role-based access controls (RBAC). Organizations need to find overly permissive


configurations and/or unnecessary roles.
Secrets. A good configuration management tool can proactively limit access to
secrets.
Policy-based assessments. Setting organizational security policies is a crucial
part of any security posture, and there should be a way to check deployments
against those pre-determined policies.
Privileges. Privileges should be assigned based on least-privileged-access
principles.
Resource limits. Both containers and Kubernetes clusters should have limits on the
CPU and memory available.
Network policies. Network policies should limit the communication between parts of
the application as much as possible to limit potential damage if a container is
compromised.

Network segmentation
By default, Kubernetes allows all pods within a cluster to communicate freely. This
makes application operations easier, but also creates a security risk. Although the
defaults are overly permissive, Kubernetes also has built-in enforcement
capabilities that can be configured to restrict communication between assets.
Network segmentation is a part of restricting communication between parts of the
deployment. Network segmentation is also required by some compliance frameworks,
including PCI-DSS.

Risk profiling

Risk profiling is the process of outlining the organization’s known security risks
and its policies and practices related to managing that risk.

In a distributed, containerized application, it can be difficult to understand and


prioritize an application’s risk profile. There might be hundreds of
vulnerabilities in any potential application, but all vulnerabilities do not have
the same risk. Security risk from a vulnerability depends on factors such as:

The severity of the vulnerability


Whether or not the application is public-facing
If the application is in production
Whether the application is in scope for compliance regulations
Whether or not the application accesses sensitive data
The container’s privilege level
The container’s network exposure

Especially at scale, risk profiling often simply isn’t possible to do without


relying on automated tools to uncover and prioritize security risks. Successful
risk profiling in Kubernetes should make use of Kubernetes’ declarative, contextual
data to automate the prioritization process. This allows security teams to focus on
fixing the highest-risk deployments first instead of spending time on the risk
profiling process.

You might also like

pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy