Create network policies

Securing the network paths for your applications is often a critical task. This tutorial walks you through explicitly opening up on the network paths needed for your application using the following areas of the Akamai App Platform:

  • Inbound rules: Pod-to-pod traffic (cluster-internal). Allow specific workloads to connect to your pods.
  • Outbound rules: External traffic (egress to FQDNs/IPs). Allow namespace‑wide access to specific FQDNs or IPs.

When Ingress control is enabled for your team, all pod‑to‑pod traffic is denied by default. When Egress control is enabled, all external traffic is denied by default.

In this lab, you will create the rules required by your voting app. The lab consists of four parts:

Deploy the voting app (Part 1)

Build container images

  1. Register a Code Repository with https://github.com/linode/apl-examples as the URL.

  2. Create three Docker Container Images. For the Dockerfile path you can use:

    • votevote-app/vote/Dockerfile
    • workervote-app/worker/Dockerfile
    • resultvote-app/result/Dockerfile

Deploy Redis & Postgres

  1. In the Catalog, install redis (master‑replica) with auth.enabled=false.
  2. Install postgresql with default settings.

Deploy your workloads

Use the k8s-deployment chart to deploy the vote app, worker app, and result app.

  • Vote:

    image:
      repository: harbor.<your-domain>/team-<team-name>/vote
      pullPolicy: IfNotPresent
      tag: main
    containerPorts:
      - name: http
        containerPort: 80
        protocol: TCP
    env:
      - name: REDIS_HOST
        value: <redis-cluster-name>-quickstart-redis-master
    replicaCount: 1
    
  • Worker:

    image:
      repository: harbor.<your-domain>/team-<team-name>/worker
      pullPolicy: IfNotPresent
      tag: main
    containerPorts:
      - name: http
        containerPort: 80
        protocol: TCP
    env:
      - name: DATABASE_USER
        valueFrom:
          secretKeyRef:
            name: <psql-cluster-name>-app
            key: username
      - name: DATABASE_PASSWORD
        valueFrom:
          secretKeyRef:
            name: <psql-cluster-name>-app
            key: password
      - name: REDIS_HOST
        value: <redis-cluster-name>-quickstart-redis-master
      - name: DATABASE_HOST
        value: <psql-cluster-name>-rw
    replicaCount: 1
    
  • Result:

    image:
      repository: harbor.<your-domain>/team-<team-name>/result
      pullPolicy: IfNotPresent
      tag: main
    containerPorts:
      - name: http
        containerPort: 80
        protocol: TCP
    env:
      - name: DATABASE_USER
        valueFrom:
          secretKeyRef:
            name: <psql-cluster-name>-app
            key: username
      - name: DATABASE_PASSWORD
        valueFrom:
          secretKeyRef:
            name: <psql-cluster-name>-app
            key: password
      - name: DATABASE_HOST
        value: <psql-cluster-name>-rw
      - name: DATABASE_NAME
        value: <psql-cluster-name>
    replicaCount: 1
    

📘

The worker and result pods will show an error “Waiting for db” in the logs. This is an expected error that will be resolved when all the steps in the lab are done.

Expose your services

Create two services, one for the vote app and one for the result app.

Create inbound rules for the voting app (Part 2)

Use the Inbound Rules page to create two rules. One allows the worker and result workloads to reach Postgres workload and the other allows the vote and worker workloads to reach Redis.

Postgres Ingress

  1. Navigate to the Inbound Rules page (under Network Policies).

  2. Click the Create inbound rule button.

  3. In theName field, enter postgres-ingress.

  4. Under Sources, add both the worker and result apps:

    • Select worker from the Workload dropdown menu.
    • Select otomi.io/app=workerfrom the Label(s) dropdown menu.
    • Click Add Source to add the second source.
    • Select result from the Workload dropdown menu.
    • Select otomi.io/app=resultfrom the Label(s) dropdown menu.
  5. Add the following in the Target section:

    • Select postgres from the Workload dropdown menu.
    • Select otomi.io/app=postgresfrom the Label(s) dropdown menu.
  6. Click Save Changes to create the rule.

Redis Ingress

  1. Click the Create inbound rule button again to create the second rule.

  2. In theName field, enter redis-ingress.

  3. Under Sources, add both the worker and vote apps:

    • Select worker from the Workload dropdown menu.
    • Select otomi.io/app=workerfrom the Label(s) dropdown menu.
    • Click Add Source to add the second source.
    • Select vote from the Workload dropdown menu.
    • Select otomi.io/app=votefrom the Label(s) dropdown menu.
  4. Add Redis to the Target section:

    • Select redis from the Workload dropdown menu.
    • Select otomi.io/app=redisfrom the Label(s) dropdown menu.
  5. Click Save Changes to create the second rule.

Create outbound rule for testing and troubleshooting (Part 3)

Use the Outbound Rules page to allow HTTPS egress to example.com so that you can test connectivity.

Example.com Egress

  1. Navigate to the Outbound Rules page (under Network Policies).

  2. Click the Create outbound rule button.

  3. In theName field, enter example-egress.

  4. For the Domain name or IP address, enter example.com.

  5. Finally set the Protocol to HTTPS and Port to 443.

  6. Click Save Changes to save your new outbound rule.

Test network traffic (Part 4)

Verify pod‑to‑pod traffic (ingress)

  1. Navigate to your Vote service’s external URL and cast a vote.
  2. Then, navigate to your Result service’s URL and confirm the vote appears. If it does, pod-to-pod traffic is working as expected.

Verify external traffic (egress)

  1. Launch Netshoot in your team namespace:

    kubectl run -i --tty --rm netshoot \
      --image nicolaka/netshoot -n team-labs
    
  2. Inside the pod, run:

     curl -s https://example.com | grep -o '<h1.*</h1>'
    

    If egress traffic is working as expected, this should display the following output:

    <h1>Example Domain</h1>
    
  3. Exit the pod (exit). It will be removed automatically.

If both tests were successful, your voting app is now locked down to exactly the paths you specified in your network policies.