Added kubernetes manifest#9
Conversation
![prisma-cloud-devsecops[bot]](https://avatars.githubusercontent.com/in/135857?s=60&v=4){kind=small}
| metadata: | ||
| name: webportal | ||
| --- | ||
| apiVersion: apps/v1 |
There was a problem hiding this comment.
Containers do not run with a high UID
Resource: Deployment.webportal.nginx-deploy | ID: BC_K8S_37
How to Fix
apiVersion: v1
kind: Pod
metadata:
name: <name>
spec:
securityContext:
+ runAsUser: <UID higher then 10000>Description
Linux namespaces provide isolation for running processes and limits access to system resources. To prevent privilege-escalation attacks from within a container, we recommend that you configure your container’s applications to run as unprivileged users. The mapped user is assigned a range of UIDs which function within the namespace as normal UIDs from 0 to 65536, but have no privileges on the host machine itself.If a process attempts to escalate privilege outside of the namespace, the process is running as an unprivileged high-number UID on the host, not mapped to a real user. This means the process has no privileges on the host system and cannot be attacked by this method.
This check will trigger below UID 10,000 as common linux distributions will assign UID 1000 to the first non-root, non system user and 1000 users should provide a reasonable buffer.
Dependent Resources
Calculating...
| metadata: | ||
| name: webportal | ||
| --- | ||
| apiVersion: apps/v1 |
There was a problem hiding this comment.
Liveness probe is not configured
Resource: Deployment.webportal.nginx-deploy | ID: BC_K8S_7
How to Fix
apiVersion: v1
kind: Pod
metadata:
name: <name>
spec:
containers:
- name: <container name>
image: <image>
+ livenessProbe:
<Probe arguments>Description
The kubelet uses liveness probes to know when to schedule restarts for containers. Restarting a container in a deadlock state can help to make the application more available, despite bugs.If a container is unresponsive, either to a deadlocked application or a multi-threading defect, restarting the container can make the application more available, despite the defect.
Dependent Resources
Calculating...
| metadata: | ||
| name: webportal | ||
| --- | ||
| apiVersion: apps/v1 |
There was a problem hiding this comment.
seccomp is not set to Docker/Default or Runtime/Default
Resource: Deployment.webportal.nginx-deploy | ID: BC_K8S_29
How to Fix
apiVersion: v1
kind: Pod
metadata:
name: <name>
spec:
containers:
- name: <container name>
image: <image>
securityContext:
+ seccompProfile:
+ type: RuntimeDefault
or
+ type: DockerDefaultDescription
Secure computing mode (seccomp) is a Linux kernel feature used to restrict actions available within the container. The seccomp() system call operates on the seccomp state of the calling process. The default seccomp profile provides a reliable setting for running containers with seccomp and disables non-essential system calls.Benchmarks
- PCI-DSS V3.2 2
- CIS KUBERNETES V1.5 1.6.4
- CIS GKE V1.1 4.6.2
- CIS EKS V1.1 4.6.1
- CIS KUBERNETES V1.6 5.7.2
Calculating...
| metadata: | ||
| name: webportal | ||
| --- | ||
| apiVersion: apps/v1 |
There was a problem hiding this comment.
Readiness probe is not configured
Resource: Deployment.webportal.nginx-deploy | ID: BC_K8S_8
How to Fix
apiVersion: v1
kind: Pod
metadata:
name: <name>
spec:
containers:
- name: <container name>
image: <image>
+ readinessProbe:
<Probe configurations>Description
Readiness Probe is a Kubernetes capability that enables teams to make their applications more reliable and robust. This probe regulates under what circumstances the pod should be taken out of the list of service endpoints so that it no longer responds to requests. In defined circumstances the probe can remove the pod from the list of available service endpoints.Using the Readiness Probe ensures teams define what actions need to be taken to prevent failure and ensure recovery in case of unexpected errors.
Dependent Resources
Calculating...
| metadata: | ||
| name: webportal | ||
| --- | ||
| apiVersion: apps/v1 |
There was a problem hiding this comment.
Admission of root containers not minimized
Resource: Deployment.webportal.nginx-deploy | ID: BC_K8S_22
How to Fix
apiVersion: v1
kind: Pod
metadata:
name: <name>
spec:
securityContext:
+ runAsNonRoot: true
+ runAsUser: <specific user>Description
Containers rely on the traditional Unix security model granting explicit and implicit permissions to resources, through permissions granted to users and groups. User namespaces are not enabled in Kubernetes. The container's user ID table maps to the host's user table, and running a process as the root user inside a container runs it as root on the host. Although possible, we do not recommend running as root inside the container.Containers that run as root usually have far more permissions than their workload requires. In case of compromise, an attacker can use these permissions to further an attack on the network. Several container images use the root user to run PID 1. An attacker will have root permissions in the container and be able to exploit mis-configurations.
Benchmarks
- SOC2 CC6.3.4
- HIPAA 164.312(A)(1) Access control
- CIS KUBERNETES V1.5 1.7.6
- CIS GKE V1.1 4.2.6
- CIS EKS V1.1 4.2.6
- CIS KUBERNETES V1.6 5.2.6
Calculating...
| metadata: | ||
| name: webportal | ||
| --- | ||
| apiVersion: apps/v1 |
There was a problem hiding this comment.
Admission of containers with NET_RAW capability is not minimized
Resource: Deployment.webportal.nginx-deploy | ID: BC_K8S_27
How to Fix
apiVersion: v1
kind: Pod
metadata:
name: <Pod name>
spec:
containers:
- name: <container name>
image: <image>
securityContext:
capabilities:
drop:
+ - NET_RAW
+ - ALLDescription
NET_RAW capability allows the binary to use RAW and PACKET sockets as well as binding to any address for transparent proxying. The *ep* stands for “effective” (active) and “permitted” (allowed to be used).With Docker as the container runtime NET_RAW capability is enabled by default and may be misused by malicious containers. We recommend you define at least one PodSecurityPolicy (PSP) to prevent containers with NET_RAW capability from launching.
Benchmarks
- SOC2 CC6.3.4
- CIS KUBERNETES V1.5 1.7.7
- CIS GKE V1.1 4.2.7
- CIS EKS V1.1 4.2.7
- CIS KUBERNETES V1.6 5.2.7
Calculating...
| metadata: | ||
| name: webportal | ||
| --- | ||
| apiVersion: apps/v1 |
There was a problem hiding this comment.
Read-Only filesystem for containers is not used
Resource: Deployment.webportal.nginx-deploy | ID: BC_K8S_21
How to Fix
apiVersion: v1
kind: Pod
metadata:
name: <Pod name>
spec:
containers:
- name: <container name>
image: <image>
securityContext:
+ readOnlyRootFilesystem: trueDescription
A read-only root filesystem helps to enforce an immutable infrastructure strategy. The container should only write on mounted volumes that can persist, even if the container exits.Using an immutable root filesystem and a verified boot mechanism prevents against attackers from "owning" the machine through permanent local changes. An immutable root filesystem can also prevent malicious binaries from writing to the host system.
Dependent Resources
Calculating...
| metadata: | ||
| name: webportal | ||
| --- | ||
| apiVersion: apps/v1 |
There was a problem hiding this comment.
securityContext is not applied to pods and containers in pod context
Resource: Deployment.webportal.nginx-deploy | ID: BC_K8S_43
How to Fix
apiVersion: v1
kind: Pod
metadata:
name: <Pod name>
spec:
containers:
- name: <container name>
image: <image>
+ securityContext:Description
**securityContext** defines privilege and access control settings for your pod or container, and holds security configurations that will be applied to a container. Some fields are present in both **securityContext** and **PodSecurityContext**, when both are set, **securityContext** takes precedence.Well-defined privilege and access control settings will enhance assurance that your pod is running with the properties it requires to function.
Dependent Resources
Calculating...
| metadata: | ||
| name: webportal | ||
| --- | ||
| apiVersion: apps/v1 |
There was a problem hiding this comment.
Admission of containers with capabilities assigned is not limited
Resource: Deployment.webportal.nginx-deploy | ID: BC_K8S_34
How to Fix
apiVersion: v1
kind: Pod
metadata:
name: <Pod name>
spec:
containers:
- name: <container name>
image: <image>
securityContext:
capabilities:
drop:
+ - ALLDescription
Docker has a default list of capabilities that are allowed for each container of a pod. The containers use the capabilities from this default list, but pod manifest authors can alter it by requesting additional capabilities, or dropping some of the default capabilities.Limiting the admission of containers with capabilities ensures that only a small number of containers have extended capabilities outside the default range. This helps ensure that if a container becomes compromised it is unable to provide a productive path for an attacker to move laterally to other containers in the pod.
Benchmarks
- SOC2 CC6.3.4
- CIS KUBERNETES V1.5 1.7.7
- CIS GKE V1.1 4.2.9
- CIS EKS V1.1 4.2.9
- CIS KUBERNETES V1.6 5.2.9
Calculating...
💰 Infracost reportMonthly estimate generatedThis comment will be updated when code changes. |
| git_org = "bmppa" | ||
| git_repo = "iac-demo" | ||
| yor_trace = "508a085e-51db-4b56-9177-c62fec5b31cd" | ||
| yor_name = "my-bucket" |
There was a problem hiding this comment.
GCP Storage buckets are publicly accessible to all users
Resource: google_storage_bucket.my-bucket | Checkov ID: CKV_GCP_114
How to Fix
resource "google_storage_bucket" "example_bucket" {
name = "example_bucket"
location = "US"
uniform_bucket_level_access = true
bucket_policy_only = true
iam_configuration {
uniform_bucket_level_access {
enabled = true
}
public_access_prevention = "enforced"
}
}Description
This policy reviews if a Google Cloud Storage bucket is safeguarded against public access. It essentially checks if measures to prevent public access are enforced on these storage buckets. If storage buckets are left publicly accessible, sensitive and private data stored within them could be exposed to unauthorized users. This potentially leads to data breaches, sabotage, or the unlawful use of this data. Therefore, this policy ensures these storage buckets are secured and not vulnerable to such risks.
| git_last_modified_at = "2021-10-05 15:00:19" | ||
| git_last_modified_by = "bm.almeida@gmail.com" | ||
| git_modifiers = "bm.almeida" | ||
| git_modifiers = "65456094+bmppa/bm.almeida" |
There was a problem hiding this comment.
AWS S3 bucket ACL grants READ permission to everyone
Resource: aws_s3_bucket.data | Checkov ID: CKV_AWS_20
How to Fix
resource "aws_s3_bucket_acl" "data" {
bucket = aws_s3_bucket.private_acl_v4.id
- acl = "public-read"
+ acl = "private"
}Description
Unprotected S3 buckets are one of the major causes of data theft and intrusions.
An S3 bucket that allows READ access to everyone can provide attackers the ability to read object data within the bucket, which can lead to the exposure of sensitive data.
The only S3 buckets that should be globally accessible for unauthenticated users or for Any AWS Authenticate Users are those used for hosting static websites.A bucket ACL helps manage access to S3 bucket data. We recommend ensuring AWS S3 buckets are not publicly accessible for READ actions to protect S3 data from unauthorized users and exposing sensitive data to public access.
2 participants
No description provided.