Skip to main content

Insecure Network Communication

Why is this important?โ€‹

Ensuring that the data in transit is secured between users and your application is the most fundamental security requirement. If this security control is not in place then all bets are off and attackers have many ways to attack your services and users.

Check out this video for a high-level explanation:

Insufficient Transport Layer Protection

Fixing Insecure Network Communicationโ€‹

Option A: Don't share the host network namespaceโ€‹

Sharing the host's network namespace permits processes in the pod to communicate with processes bound to the host's loopback adapter, which could expose internal services to attackers.

Detailed Instructionsโ€‹

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

  2. Look for code like this:

    apiVersion: policy/v1beta1
    kind: PodSecurityPolicy
    metadata:
    name: host-network
    spec:
    hostNetwork: true
  3. Replace the line containing hostNetwork: true with:

    spec:
    hostNetwork: false
  4. Test it

  5. Ship it ๐Ÿšข and relax ๐ŸŒด

Option B: Don't use hostAliases to manage DNS entriesโ€‹

Managing /etc/hosts aliases can prevent the container from modifying the file after a pod's containers have already been started. DNS should be managed by the orchestrator and not via /etc/hosts entries.

Detailed Instructionsโ€‹

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

  2. Look for code like this:

    apiVersion: v1
    kind: Pod
    metadata:
    name: hostaliases-pod
    spec:
    restartPolicy: Never
    hostAliases:
    - ip: "127.0.0.1"
    hostnames:
    - "foo.local"
    - "bar.local"
  3. Remove the hostAliases from the spec:

    apiVersion: v1
    kind: Pod
    metadata:
    name: hostaliases-pod
    spec:
    restartPolicy: Never
  4. Test it

  5. Ship it ๐Ÿšข and relax ๐ŸŒด

More information:โ€‹