GuardRails

GuardRails

  • Languages iconEnglish
    • 中文

›Kubernetes

Overview

  • Introduction
  • What is GuardRails
  • Getting started
  • Findings
  • Vulnerabilities
  • Configuration
  • Custom Engines
  • False Positives
  • Enforce Passing Checks
  • Build Status on Pull Requests
  • FAQ
  • Pricing
  • Glossary
  • Tools & Licenses

API

  • Usage Guide
  • Endpoints

Vulnerabilities

  • Introduction
  • General

    • Overview
    • Hard-Coded Secrets

    Apex

    • Overview
    • Insecure Access Control
    • Insecure Network Communication
    • Insecure Processing of Data
    • Insecure Use of Cryptography
    • Insecure Use of Language/Framework API
    • Insecure Use of SQL Queries

    C/C++

    • Overview
    • Insecure Access Control
    • Insecure File Management
    • Insecure Processing of Data
    • Insecure Use of Cryptography
    • Insecure Use of Dangerous Function

    Dotnet

    • Overview
    • Insecure Access Control
    • Insecure Configuration
    • Insecure File Management
    • Insecure Processing of Data
    • Insecure Use of Cryptography
    • Insecure Use of Dangerous Function
    • Insecure Use of SQL Queries
    • Using Vulnerable Libraries

    Elixir

    • Overview
    • Insecure Configuration
    • Insecure File Management
    • Insecure Processing of Data
    • Insecure Network Communication
    • Insecure Use of Dangerous Function
    • Insecure Use of Language/Framework API
    • Insecure Use of SQL Queries
    • Using Vulnerable Libraries

    Go

    • Overview
    • Insecure File Management
    • Insecure Network Communication
    • Insecure Processing of Data
    • Insecure Use of Cryptography
    • Insecure Use of Dangerous Function
    • Insecure Use of SQL Queries
    • Using Vulnerable Libraries

    Java

    • Overview
    • Using Vulnerable Libraries
    • Insecure Use of SQL Queries
    • Insecure Use of Dangerous Function
    • Insecure Use of Regular Expressions
    • Insecure Authentication
    • Insecure Configuration
    • Insecure File Management
    • Insecure Use of Cryptography
    • Insecure Use of Language/Framework API
    • Insecure Processing of Data
    • Insecure Network Communication

    Javascript/TypeScript

    • Overview
    • Insecure Authentication
    • Insecure Processing of Data
    • Insecure Use of SQL Queries
    • Insecure Use of Regular Expressions
    • Insecure Use of Language/Framework API
    • Insecure Use of Dangerous Function
    • Using Vulnerable Libraries

    Kubernetes

    • Overview
    • Insecure Access Control
    • Insecure Configuration
    • Insecure Network Communication

    PHP

    • Overview
    • Insecure Configuration
    • Insecure File Management
    • Insecure Network Communication
    • Insecure Processing of Data
    • Insecure Use of Dangerous Function
    • Insecure Use of Language/Framework API
    • Insecure Use of Regular Expressions
    • Insecure Use of SQL Queries
    • Using Vulnerable Libraries

    Python

    • Overview
    • Insecure Configuration
    • Insecure Use of Cryptography
    • Insecure Network Communication
    • Insecure Processing of Data
    • Insecure Use of Dangerous Function
    • Insecure Use of SQL Queries
    • Using Vulnerable Libraries

    Ruby

    • Overview
    • Insecure Access Control
    • Insecure Configuration
    • Insecure File Management
    • Insecure Network Communication
    • Insecure Processing of Data
    • Insecure Use of Dangerous Function
    • Insecure Use of Language/Framework API
    • Insecure Use of Regular Expressions
    • Insecure Use of SQL Queries
    • Using Vulnerable Libraries

    Rust

    • Overview
    • Using Vulnerable Libraries

    Solidity

    • Overview
    • Insecure Integer Arithmetic
    • Insecure Use of Low-Level Call
    • Reliance on Insecure Random Numbers
    • State Change After External Call
    • Transaction Order Dependence
    • Unprotected Critical Function
    • Use of Insecure Function
    • Dependence on Predictable Environment Variables
    • Write to Arbitrary Storage Location
    • Call to Untrusted Contract

    Terraform

    • Overview
    • Hard-Coded Secrets
    • Insecure Access Control
    • Insecure Configuration
    • Insecure Network Communication
    • Insecure Use of Cryptography

Insecure Access Control

Why is this important?

Access Control is one of the most fundamental security requirements. Any problem with managing access control can allow attackers to bypass business logic and access data from other users. In the context of Kubernetes this affects settings related to the securityContext and spec.

Check out this video for a high-level explanation:

Access Control Issues

Insecure SecurityContext Settings

This category refers to SecurityContext settings that are insecure.

Option A: Run containers as non-root users

Force the running image to run as a non-root user to ensure least privilege.

Detailed Instructions

  1. Go through the issues that GuardRails identified.
  2. Look for code like this:
apiVersion: v1  
kind: Pod  
metadata:  
  name: security-best-practice
spec:  
  containers:  
  # specification of the pod’s containers  
  # ...  
  securityContext:  
    runAsNonRoot: false
  # it is also possible for runAsNonRoot to not be set.
  1. Replace the line containing runAsNonRoot: false with:
spec:  
  containers:
  # specification of the pod’s containers  
  # ...  
  securityContext:  
    runAsNonRoot: true
  1. Test it
  2. Ship it 🚢 and relax 🌴

Option B: Don't run containers in privileged mode

Privileged containers can allow almost completely unrestricted host access.

Detailed Instructions

  1. Go through the issues that GuardRails identified.
  2. Look for code like this:
apiVersion: v1  
kind: Pod  
metadata:  
  name: security-best-practice
spec:  
  containers:  
  # specification of the pod’s containers  
  # ...  
  securityContext:  
    privileged: true
  1. Replace the line containing privileged: false with:
spec:  
  containers:
  # specification of the pod’s containers  
  # ...  
  securityContext:  
    privileged: false
  1. Test it
  2. Ship it 🚢 and relax 🌴

Option C: Don't add SYS_ADMIN capabilities

Capabilities permit certain named root actions without giving full root access. They are a more fine-grained permissions model, and all capabilities should be dropped from a pod, with only those required added back.

There are a large number of capabilities, with CAP_SYS_ADMIN bounding most. Never enable this capability - it’s equivalent to root and should always be avoided.

Detailed Instructions

  1. Go through the issues that GuardRails identified.
  2. Look for code like this:
apiVersion: v1  
kind: Pod  
metadata:
  name: sys-admin-capabilities
spec:
  containers:
  # specification of the pod’s containers
  # ...
  securityContext:
    capabilities:
      drop:
        - all
      add:
        - SYS_ADMIN
  1. Remove the SYS_ADMIN capabilities.
  2. Test it
  3. Ship it 🚢 and relax 🌴

Option D: Disable allowPrivilegeEscalation

Gates whether or not a user is allowed to set the security context of a container to allowPrivilegeEscalation. This defaults to allowed so as to not break setuid binaries. Setting it to false ensures that no child process of a container can gain more privileges than its parent.

Detailed Instructions

  1. Go through the issues that GuardRails identified.
  2. Look for container definitions with allowPrivilegeEscalation being set to true.
apiVersion: v1
kind: Pod  
metadata:
  name: drop-capabilities
spec:
  containers:
  # specification of the pod’s containers
  # ...
  securityContext:
    allowPrivilegeEscalation: true
  1. Change it to allowPrivilegeEscalation: false.
  2. Test it
  3. Ship it 🚢 and relax 🌴

Option E: Reduce kernel capabilities

Reducing kernel capabilities available to a container limits its attack surface. It's recommended to drop all capabilities and only add the ones specifically needed.

Detailed Instructions

  1. Go through the issues that GuardRails identified.
  2. Look for container definitions without capabilities definition in the securityContext.
  3. Drop all capabilities and add the ones needed.
apiVersion: v1
kind: Pod  
metadata:
  name: drop-capabilities
spec:
  containers:
  # specification of the pod’s containers
  # ...
  securityContext:
    capabilities:
      drop:
        - all
      add: ["NET_ADMIN", "SYS_TIME"]
  1. Test it
  2. Ship it 🚢 and relax 🌴

Option F: Run as high-UID user

Run as a high-UID user to avoid conflicts with the host's user table. While this is not a high-risk issue it is recommended to set a UID higher than 10000.

Detailed Instructions

  1. Go through the issues that GuardRails identified.
  2. Look for container definitions like this:
apiVersion: v1
kind: Pod  
metadata:
  name: run-as-user
spec:
  containers:
  # specification of the pod’s containers
  # ...
  securityContext:
    runAsUser: 1000
  1. Change the value to a number higher than 10000.
  2. Test it
  3. Ship it 🚢 and relax 🌴

Insecure Spec Settings

This category refers to Spec settings that are insecure.

Option A: Disable HostPID

Sharing the host's PID namespace allows visibility of processes on the host, potentially leaking information such as environment variables and configuration.

Detailed Instructions

  1. Go through the issues that GuardRails identified.
  2. Look for spec definitions like this:
apiVersion: v1
kind: Pod  
metadata:
  name: run-as-user
spec:
  hostPID: true
  1. Change the value of hostPID to false.
  2. Test it
  3. Ship it 🚢 and relax 🌴

More information:

  • Configure Service Account
← OverviewInsecure Configuration →
  • Why is this important?
  • Insecure SecurityContext Settings
    • Option A: Run containers as non-root users
    • Option B: Don't run containers in privileged mode
    • Option C: Don't add SYS_ADMIN capabilities
    • Option D: Disable allowPrivilegeEscalation
    • Option E: Reduce kernel capabilities
    • Option F: Run as high-UID user
  • Insecure Spec Settings
    • Option A: Disable HostPID
  • More information:
  • Status
  • Help
  • Security
  • Terms
  • Privacy

© 2021 GuardRails