DIY Deployment of SafeLine WAF on K8s

Environment:

• Operating System: CentOS Linux release 7.9.2009
• Kernel Version: 3.10.0-1160.92.1.el7.x86_64

DIY Process:
0. Customizing Pod Configuration Files
Using the compose.yaml file provided by the official documentation, I created a set of K8s pod configurations necessary to run the various services. You can load and start the pods directly from these configurations. (You can find the detailed configuration in the attached file on GitHub: safeline-ce-k8s-yaml.zip).

1. Checking Pod Status
Run the following command to check the status of your pods:

[root@master safeline-ce]# kubectl get pods,svc,pvc -n waf -o wide

The output should show all relevant pods, services, and persistent volume claims (PVCs) in a running state. Here’s a sample output:

NAME                                     READY   STATUS    RESTARTS   AGE     IP                NODE                 NOMINATED NODE   READINESS GATES
pod/safeline-detector-54bfb6f99c-gtlmt   1/1     Running   0          12m     100.100.246.231   master.k8s.local     <none>           <none>
pod/safeline-mario-779b744447-zq5tc      1/1     Running   0          12m     100.109.175.106   worker01.k8s.local   <none>           <none>
pod/safeline-mgt-api-5d65b8b49-txv4f     1/1     Running   0          6m33s   192.168.5.6       master.k8s.local     <none>           <none>
pod/safeline-tengine-684cff57fb-rtb6m    1/1     Running   0          12m     192.168.5.8       worker02.k8s.local   <none>           <none>

2. Modifying the PostgreSQL Database Address
2.1 Inside the safeline-mgt-api Container
Navigate to the /app/nginx directory within the safeline-mgt-api container and update the nginx.conf file with the correct PostgreSQL service address for your K8s cluster:

upstream postgres {
    #server safeline-postgres:5432;
    # Replace with your K8s PostgreSQL address
    server postgresql-hl.middleware:5432;
}

After updating the address, restart the Nginx service with supervisorctl restart nginx and confirm its status with supervisorctl status.

2.2 Inside the safeline-mario Container
In the safeline-mario container, go to the /mario directory and update the pg connection URL in the config.yml file with your PostgreSQL address and credentials:

handler:
  plumber: {}
  persistence:
    postgres:
      # Replace with your K8s PostgreSQL address and password
      url: postgres://safeline-ce:<postgres-password>@postgresql-hl.middleware:5432/safeline-ce

Once updated, commit the container changes to a new Docker image and restart the service with the new image.

3. Switching from UNIX Socket to Network Socket Communication

Since SafeLine is deployed in K8s, where each pod is in a different network namespace, you need to change the communication between safeline-detector and safeline-tengine from UNIX socket to network socket (IP + port).

3.1 Inside the safeline-detector Container
Go to the /resources/detector directory and update the snserver.yml configuration:

Before:

bind_addr: unix:///resources/detector/snserver.sock
# bind_addr: 0.0.0.0

After:

#bind_addr: unix:///resources/detector/snserver.sock
bind_addr: 0.0.0.0
listen_port: 8000

Reload the configuration with kill -1 1, and verify that the ports are listening:

root@safeline-detector:/resources/detector# netstat -nplt

3.2 Inside the safeline-tengine Container
In the /root/nginx directory, modify the nginx.conf file:

Before:

include /etc/nginx/safeline_unix.conf;

After:

#include /etc/nginx/safeline_unix.conf;
include /etc/nginx/safeline.conf;  # Switch to network socket mode

Also, update the config.yml in the /root/tcontrollerd directory:

Before:

mgt_addr: 169.254.0.2:9002

After:

mgt_addr: safeline-mgt-api:9002

Usage

• Access the SafeLine management API by navigating to the host node’s IP on port 1443.

• Add the sites you wish to protect, and then review the dashboard data.

• Test the interception functionality.

Conclusion

Pros:

• Open-source: Customizable to suit various deployment needs.
• Security: Meets most small and medium-sized businesses' security requirements.

Cons:

• Documentation: Lacks details on each service's roles and purposes, which can make deployment tricky.
• Configuration: Unclear which configurations take precedence (environment variables or config files). It’s recommended that the documentation clarify this and, if possible, use environment variables.