Get Started
- CodeAnt AI
- Setup
- Control Center
- Pull Request Review
- IDE
- Compliance
- Anti-Patterns
- Code Governance
- Infrastructure Security Database
- Application Security Database
- Apex
- Bash
- C
- Clojure
- Cpp
- Csharp
- Dockerfile
- Elixir
- Fingerprints
- Generic
- Go
- Html
- Java
- Javascript
- Json
- Kotlin
- Ocaml
- Php
- Problem-based-packs
- Python
- Ruby
- Rust
- Scala
- Solidity
- Swift
- Terraform
- Typescript
- Yaml
- Argo
- Docker-compose
- Github-actions
- Gitlab
- Kubernetes
- Best practice
- Security
- Security
- Openapi
- Semgrep
- Semgrep
Security
When running containers in Kubernetes, it’s important to ensure that they are properly secured to prevent privilege escalation attacks. One potential vulnerability is when a container is allowed to run applications as the root user, which could allow an attacker to gain access to sensitive resources. To mitigate this risk, it’s recommended to add a securityContext to the container, with the parameter runAsNonRoot set to true. This will ensure that the container runs as a non-root user, limiting the damage that could be caused by any potential attacks. By adding a securityContext to the container in your Kubernetes pod, you can help to ensure that your containerized applications are more secure and less vulnerable to privilege escalation attacks.
Likelihood: LOW
Confidence: LOW
CWE:
- CWE-250: Execution with Unnecessary Privileges
OWASP:
- A05:2021 - Security Misconfiguration
- A06:2017 - Security Misconfiguration
Container is explicitly disabling seccomp confinement. This runs the service in an unrestricted state. Remove ‘seccompProfile: unconfined’ to prevent this.
Likelihood: MEDIUM
Confidence: MEDIUM
CWE:
- CWE-284: Improper Access Control
OWASP:
- A05:2017 - Broken Access Control
- A01:2021 - Broken Access Control
In Kubernetes, each pod runs in its own isolated environment with its own set of security policies. However, certain container images may contain setuid or setgid binaries that could allow an attacker to perform privilege escalation and gain access to sensitive resources. To mitigate this risk, it’s recommended to add a securityContext to the container in the pod, with the parameter allowPrivilegeEscalation set to false. This will prevent the container from running any privileged processes and limit the impact of any potential attacks. In the container $CONTAINER this parameter is set to true which makes this container much more vulnerable to privelege escalation attacks.
Likelihood: MEDIUM
Confidence: MEDIUM
CWE:
- CWE-732: Incorrect Permission Assignment for Critical Resource
OWASP:
- A05:2021 - Security Misconfiguration
- A06:2017 - Security Misconfiguration
When running containers in Kubernetes, it’s important to ensure that they are properly secured to prevent privilege escalation attacks. One potential vulnerability is when a container is allowed to run applications as the root user, which could allow an attacker to gain access to sensitive resources. To mitigate this risk, it’s recommended to add a securityContext to the container, with the parameter runAsNonRoot set to true. This will ensure that the container runs as a non-root user, limiting the damage that could be caused by any potential attacks. By adding a securityContext to the container in your Kubernetes pod, you can help to ensure that your containerized applications are more secure and less vulnerable to privilege escalation attacks.
Likelihood: LOW
Confidence: LOW
CWE:
- CWE-250: Execution with Unnecessary Privileges
OWASP:
- A05:2021 - Security Misconfiguration
- A06:2017 - Security Misconfiguration
Container or pod is running in privileged mode. This grants the container the equivalent of root capabilities on the host machine. This can lead to container escapes, privilege escalation, and other security concerns. Remove the ‘privileged’ key to disable this capability.
Likelihood: MEDIUM
Confidence: MEDIUM
CWE:
- CWE-250: Execution with Unnecessary Privileges
Pod is sharing the host process ID namespace. When paired with ptrace this can be used to escalate privileges outside of the container. Remove the ‘hostPID’ key to disable this functionality.
Likelihood: LOW
Confidence: LOW
CWE:
- CWE-269: Improper Privilege Management
OWASP:
- A04:2021 - Insecure Design
Cluster is disabling TLS certificate verification when communicating with the server. This makes your HTTPS connections insecure. Remove the ‘insecure-skip-tls-verify: true’ key to secure communication.
Likelihood: MEDIUM
Confidence: MEDIUM
CWE:
- CWE-319: Cleartext Transmission of Sensitive Information
OWASP:
- A03:2017 - Sensitive Data Exposure
- A02:2021 - Cryptographic Failures
Pod may use the node network namespace. This gives the pod access to the loopback device, services listening on localhost, and could be used to snoop on network activity of other pods on the same node. Remove the ‘hostNetwork’ key to disable this functionality.
Likelihood: LOW
Confidence: LOW
CWE:
- CWE-406: Insufficient Control of Network Message Volume (Network Amplification)
Secrets ($VALUE) should not be stored in infrastructure as code files. Use an alternative such as Bitnami Sealed Secrets or KSOPS to encrypt Kubernetes Secrets.
Likelihood: LOW
Confidence: MEDIUM
CWE:
- CWE-798: Use of Hard-coded Credentials
OWASP:
- A07:2021 - Identification and Authentication Failures
When running containers in Kubernetes, it’s important to ensure that they are properly secured to prevent privilege escalation attacks. One potential vulnerability is when a container is allowed to run applications as the root user, which could allow an attacker to gain access to sensitive resources. To mitigate this risk, it’s recommended to add a securityContext to the container, with the parameter runAsNonRoot set to true. This will ensure that the container runs as a non-root user, limiting the damage that could be caused by any potential attacks. By adding a securityContext to the container in your Kubernetes pod, you can help to ensure that your containerized applications are more secure and less vulnerable to privilege escalation attacks.
Likelihood: LOW
Confidence: LOW
CWE:
- CWE-250: Execution with Unnecessary Privileges
OWASP:
- A05:2021 - Security Misconfiguration
- A06:2017 - Security Misconfiguration
When running containers in Kubernetes, it’s important to ensure that they are properly secured to prevent privilege escalation attacks. One potential vulnerability is when a container is allowed to run applications as the root user, which could allow an attacker to gain access to sensitive resources. To mitigate this risk, it’s recommended to add a securityContext to the container, with the parameter runAsNonRoot set to true. This will ensure that the container runs as a non-root user, limiting the damage that could be caused by any potential attacks. By adding a securityContext to the container in your Kubernetes pod, you can help to ensure that your containerized applications are more secure and less vulnerable to privilege escalation attacks.
Likelihood: LOW
Confidence: LOW
CWE:
- CWE-250: Execution with Unnecessary Privileges
OWASP:
- A05:2021 - Security Misconfiguration
- A06:2017 - Security Misconfiguration
Container $CONTAINER is running with a writable root filesystem. This may allow malicious applications to download and run additional payloads, or modify container files. If an application inside a container has to save something temporarily consider using a tmpfs. Add ‘readOnlyRootFilesystem: true’ to this container to prevent this.
Likelihood: LOW
Confidence: LOW
CWE:
- CWE-732: Incorrect Permission Assignment for Critical Resource
OWASP:
- A05:2021 - Security Misconfiguration
- A06:2017 - Security Misconfiguration
In Kubernetes, each pod runs in its own isolated environment with its own set of security policies. However, certain container images may contain setuid or setgid binaries that could allow an attacker to perform privilege escalation and gain access to sensitive resources. To mitigate this risk, it’s recommended to add a securityContext to the container in the pod, with the parameter allowPrivilegeEscalation set to false. This will prevent the container from running any privileged processes and limit the impact of any potential attacks. By adding the allowPrivilegeEscalation parameter to your the securityContext, you can help to ensure that your containerized applications are more secure and less vulnerable to privilege escalation attacks.
Likelihood: MEDIUM
Confidence: MEDIUM
CWE:
- CWE-732: Incorrect Permission Assignment for Critical Resource
OWASP:
- A05:2021 - Security Misconfiguration
- A06:2017 - Security Misconfiguration
Service is disabling TLS certificate verification when communicating with the server. This makes your HTTPS connections insecure. Remove the ‘insecureSkipTLSVerify: true’ key to secure communication.
Likelihood: MEDIUM
Confidence: MEDIUM
CWE:
- CWE-319: Cleartext Transmission of Sensitive Information
OWASP:
- A03:2017 - Sensitive Data Exposure
- A02:2021 - Cryptographic Failures
In Kubernetes, each pod runs in its own isolated environment with its own set of security policies. However, certain container images may contain setuid or setgid binaries that could allow an attacker to perform privilege escalation and gain access to sensitive resources. To mitigate this risk, it’s recommended to add a securityContext to the container in the pod, with the parameter allowPrivilegeEscalation set to false. This will prevent the container from running any privileged processes and limit the impact of any potential attacks. By adding a securityContext to your Kubernetes pod, you can help to ensure that your containerized applications are more secure and less vulnerable to privilege escalation attacks.
Likelihood: MEDIUM
Confidence: MEDIUM
CWE:
- CWE-732: Incorrect Permission Assignment for Critical Resource
OWASP:
- A05:2021 - Security Misconfiguration
- A06:2017 - Security Misconfiguration
Semgrep detected a Kubernetes core API ClusterRole with excessive permissions. Attaching excessive permissions to a ClusterRole associated with the core namespace allows the V1 API to perform arbitrary actions on arbitrary resources attached to the cluster. Prefer explicit allowlists of verbs/resources when configuring the core API namespace.
Likelihood: MEDIUM
Confidence: HIGH
CWE:
- CWE-269: Improper Privilege Management
OWASP:
- A05:2021 - Security Misconfiguration
- A06:2017 - Security Misconfiguration
Exposing host’s Docker socket to containers via a volume. The owner of this socket is root. Giving someone access to it is equivalent to giving unrestricted root access to your host. Remove ‘docker.sock’ from hostpath to prevent this.
Likelihood: LOW
Confidence: MEDIUM
CWE:
- CWE-250: Execution with Unnecessary Privileges
When running containers in Kubernetes, it’s important to ensure that they are properly secured to prevent privilege escalation attacks. One potential vulnerability is when a container is allowed to run applications as the root user, which could allow an attacker to gain access to sensitive resources. To mitigate this risk, it’s recommended to add a securityContext to the container, with the parameter runAsNonRoot set to true. This will ensure that the container runs as a non-root user, limiting the damage that could be caused by any potential attacks. By adding a securityContext to the container in your Kubernetes pod, you can help to ensure that your containerized applications are more secure and less vulnerable to privilege escalation attacks.
Likelihood: MEDIUM
Confidence: MEDIUM
CWE:
- CWE-250: Execution with Unnecessary Privileges
OWASP:
- A05:2021 - Security Misconfiguration
- A06:2017 - Security Misconfiguration
Pod is sharing the host IPC namespace. This allows container processes to communicate with processes on the host which reduces isolation and bypasses container protection models. Remove the ‘hostIPC’ key to disable this functionality.
Likelihood: LOW
Confidence: LOW
CWE:
- CWE-693: Protection Mechanism Failure