8장. Build-time network policy tools

Prerequisites

1. The build-time network policy generator recursively scans the directory you specify when you run the command. Therefore, before you run the command, you must already have service manifests, config maps, and workload manifests such as Pod, Deployment, ReplicaSet, Job, DaemonSet, and StatefulSet as YAML files in the specified directory.
2. Verify that you can apply these YAML files by using the kubectl apply -f command. The build-time network policy generator does not work with files that use Helm style templating.

3. Verify that the service network addresses are not hard-coded. Every workload that needs to connect to a service must specify the service network address as a variable. You can specify this variable by using the workload’s resource environment variable or in a config map.

   • Example 1: Using an environment variable
   • Example 2: Using a config map
   • Example 3: Using a config map

4. Service network addresses must match the following official regular expression pattern:

   (http(s)?://)?<svc>(.<ns>(.svc.cluster.local)?)?(:<portNum>)?

   • <svc> is the service name.
   • <ns> is the namespace where you defined the service.
   • <portNum> is the exposed service port number.

   Following are some examples that match the pattern:

   • wordpress-mysql:3306
   • redis-follower.redis.svc.cluster.local:6379
   • redis-leader.redis
   • http://rating-service.

Procedure

1. Verify that the build-time network policy generation feature is available by running the help command:

   $ roxctl netpol generate -h

2. Generate the policies by using the netpol generate command:

   $ roxctl netpol generate <folder_path> [flags]

   where:

   <folder_path>

   Specifies the path to the folder, which can include sub-folders that contain YAML resources for analysis. The command scans the entire sub-folder tree. Optionally, you can also specify parameters to change the behavior of the command.