Skip to main content

Insecure Configuration

Fixing Insecure Configuration​

About Insecure Configuration

What is Insecure Configuration?​

Insecure configuration refers to the situation where a system or application is configured with settings or parameters that do not adequately protect it against security threats.

Examples of insecure configurations include using default or weak passwords, allowing open access to network ports, enabling unnecessary services or protocols, and misconfiguring access controls.

Insecure configuration can occur at any layer of the technology stack, including hardware, operating systems, applications, and network devices.

It is a common cause of security incidents and is often exploited by attackers who take advantage of misconfigured systems to gain access to sensitive information or carry out attacks.

Check out this video for a high-level explanation:

What is the impact of Insecure Configuration?​

The impact of insecure configuration can lead to financial and reputational losses and potential harm to individuals or organizations.

Insecure configurations can leave systems and applications vulnerable to a variety of security threats, including unauthorized access, data breaches, and denial of service. Attackers can exploit insecure configurations to gain access to sensitive information, steal data, install malware or ransomware, or disrupt services.

In addition to the direct financial and operational costs of such attacks, insecure configurations can also result in lost business, damage to brand reputation, and legal or regulatory penalties.

Insecure configurations can also make it difficult for organizations to comply with security and privacy regulations, such as GDPR, HIPAA, and PCI DSS. Non-compliance with these regulations can result in significant fines, legal actions, and reputational damage.

How to prevent Insecure Configuration?​

To prevent insecure configuration, it is important to follow security best practices and guidelines, such as those provided by industry standards like NIST or CIS, and to regularly review and update configurations to ensure they are up-to-date and properly secured.

Here are some specific steps you can take to prevent insecure configuration:

  • Use secure defaults: Always change the default configuration settings of software and hardware devices to more secure settings, such as changing default passwords and disabling unnecessary services.
  • Limit access: Implement the principle of least privilege and limit access to systems and applications only to authorized users who need it to perform their job duties.
  • Apply security updates: Keep systems and applications up-to-date with the latest security patches and updates to protect against known vulnerabilities.
  • Use security tools: Deploy security tools, such as vulnerability scanners and security information and event management (SIEM) systems, to monitor and manage system configurations.
  • Enforce strong passwords: Require the use of strong passwords and two-factor authentication for accessing systems and applications.
  • Follow security standards and frameworks: Implement security standards and frameworks, such as NIST or CIS, to ensure that your configurations adhere to industry best practices.
  • Regularly review and audit configurations: Regularly review and audit system configurations to ensure they are properly secured and to identify and address any vulnerabilities or misconfigurations.

By taking these steps, you can significantly reduce the risk of insecure configuration and protect your systems and applications from security threats.

References​

Taxonomies​

Training​

Container Runs Unmasked​

Option A: Make sure AllowedProcMountTypes is Set to Default​

Check if a container has full access (Unmasked) to the host's /proc command, which would allow the retrieval of sensitive information and potentially change the kernel parameters at runtime.

Solution-specific references:

  1. Set your Pod Security Policy so that spec.allowedProcMountTypes contains the value Default and not Unmasked
  2. Test it
  3. Ship it 🚢 and relax 🌴

Default Service Account In Use​

Rule-specific references:

Option A: Make sure AutomountServiceAccountToken is set to false​

Default service accounts should not be actively used

  1. opt out of automounting API credentials for a service account by setting automountServiceAccountToken: false on the service account:

    apiVersion: v1
    kind: ServiceAccount
    metadata:
      name: build-robot
    automountServiceAccountToken: false
    ...

    In version 1.6+, you can also opt out of automounting API credentials for a particular pod:

    apiVersion: v1
    kind: Pod
    metadata:
      name: my-pod
    spec:
      serviceAccountName: build-robot
      automountServiceAccountToken: false
    ...

    The pod spec takes precedence over the service account if both specify an automountServiceAccountToken value

  2. Test it

  3. Ship it 🚢 and relax 🌴

Insecure Volumes Configuration​

Rule-specific references:

Option A: Don't mount the docker socket​

Mounting the docker.socket leaks information about other containers and in some instances can allow container breakout.

  1. Go through the issues that GuardRails identified in the PR/MR

  2. Look for code like this:

    apiVersion: v1
    kind: Pod
    metadata:
      name: volume-hostpath
    spec:
      []...]
      volumes:
      - name: test-volume
        hostPath:
          path: /var/run/docker.sock

  3. And remove any paths that mount the docker.sock

  4. Test it

  5. Ship it 🚢 and relax 🌴

Insecure Security Context Configuration​

Option A: Leverage immutable root file-systems​

An immutable root filesystem can prevent malicious binaries from being added to PATH and increase attack cost as well as avoid modification of the application source at runtime.

  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:  
        readOnlyRootFilesystem: false
      # it is also possible for readOnlyRootFilesystem to not be set.

  3. Replace the line containing readOnlyRootFilesystem: false with:

    spec:  
      containers:
      # specification of the pod’s containers  
      # ...  
      securityContext:  
        readOnlyRootFilesystem: true

  4. Test it

  5. Ship it 🚢 and relax 🌴

Missing Resource Limitations​

Kubernetes allows setting resource limitations on CPU and memory which can be useful to prevent denial of service attacks, or very high cloud provider bills. While this is not a high-risk issue, it is considered best practice to set these limitations.

Option A: Enforce limits​

Enforcing CPU/memory requests helps the fair balancing of resources across the cluster. Enforcing CPU/memory limits prevents DOS via resource exhaustion.

  1. Go through the issues that GuardRails identified

  2. Identify container specs that don't have resource limitations

  3. Add CPU and memory limitations to the configuration

    apiVersion: v1
    kind: Pod
    metadata:
      name: default-mem-demo-3
    spec:
      containers:
      - name: default-mem-demo-3-ctr
        image: nginx
        resources:
          requests:
            memory: "128Mi"
            cpu: 500m
          limits:
            memory: "512Mi"
            cpu: "1"

  4. Test it

  5. Ship it 🚢 and relax 🌴

PSP With Added Capabilities​

Rule-specific references:

Option A: Make sure AllowedCapabilities is Empty​

PodSecurityPolicy should not have added capabilities.

  1. Set your Pod Security Policy so that spec.allowedCapabilities either does not exist or does not contain any capabilities
  2. Test it
  3. Ship it 🚢 and relax 🌴
Last updated on by Stefan Streichsbier