You can create connection rules that filter connections according to Layer 7 attributes, such as specific HTTP actions (GET, POST, etc), or message brokered actions (read, write). With this, you can define a policy to regulate workload connections in your environments based on the content of the message, and not the source and destination.

You can create two types of Layer 7 filters:

• HTTP messages - these are specific HTTP requests, for specific methods and URLs, such as POST /api/yourdomain/amethod
• Brokered messages (such as Kafka) - these are messages brokered through services such as Kafka

HTTP methods

You can filter connection traffic for specific HTTP requests, by selecting methods, such as GET or POST, and URL paths. These can then be configured as ALLOW or BLOCK/DETECT rules. In this way you can control which HTTP requests are permitted. You can use this in combination with specific source and destination settings for the rule.

Service brokered messages (Kafka)

You can create connection rules for connections involving service brokers, such as Kafka, if you are using these services in your clusters. Message brokers act as a messaging service to securely deliver and (if necessary) store messages between services. Services connect to the broker to send or retrieve messages, instead of connecting directly with each other. This is useful, for example, if a service has many instances, and the next available instance should take the next message from the queue.

Message brokers such as Kafka work at Layer 7 (the application layer). You can use them to control message traffic to services according to topics, and the action (read or write), and not simply according to the source and destination services (L3/L4). This gives a greater degree of granularity in managing the traffic.

Panoptica Connection rules using brokers use the broker as the destination, instead of the actual destination workload. You can set up rules between services according to message topics, and according to the read or write action performed.

These types of rules have additional parameters (described below), such as the message topic, and the action.

Panoptica supports strimzi Kafka, using OPA.

Use-case example

In the example below, two microservices, acting as client and server, each with multiple instances, use kafka as a message broker for communication, so that the client (sender) need not be aware of the actual destination server (receiver) instance. In this case, two Panoptica connection rules could control the traffic, permitting the client to write messages, and the server to read them:

client workload (pod) can write to kafka broker X on topic Y

server workload (pod) can read from kafka broker X on topic Y

For both rules in this example, the kafka broker is the destination.

Configure Kafka

Configuration for Kafka

On the kafka namespace in your cluster, add this label, to enable Panoptica to manage it:

kubectl label namespace <kafka-ns> istio-injection=enabled --overwrite

On the kafka pods, add these annotations:

sidecar.istio.io/inject: false

auth.portshift.io/kafka: true

Then, restart the pods.

Configuration for Strimzi

If you are using Strimzi for Kafka on your cluster, it is necessary to enable Panoptica.

Edit the Kafka CRD, using the following:

kubectl edit kafkas.kafka.strimzi.io -n <kafka ns> <kafka CRD name>

Add the following under spec.kafka:

authorization:
      allowOnError: true
      expireAfterMs: 30000
      type: opa
      url: http://portshift-agent.portshift:8181/kafka/authz

The values for allowOnError and expireAfterMs are recommended settings, and can be adjusted per need. See also this blog post for more details.

Add this label (in the Kafka CRD), under spec.kafka:

template:
      pod:
        metadata:         
         labels:
            portshift.io/app: kafka

If Istio is installed and configured for automatic injection, and this annotation istio-injection=enabled is set in the kafka namespace, add this annotation (under spec.kafka):

template:
      pod:
        metadata:
          annotations:
            sidecar.istio.io/inject: false

Create a Layer 7 filter for a connection rule

A connection rule with Layer 7 filtering is similar to a normal connection rule, but additional filtering options are included.

1. Navigate to the POLICIES page and select the CONNECTION RULES tab.
2. Create New Connection Rule.
3. For STEP 1, the source, select the source for the connection (see Connection Policy) for details for this step. Click NEXT to move to STEP 2.
4. For STEP 2, select the destination. For service brokered filtering (Kafka), select By Kafka (or another broker) and the cluster.

5. For STEP 3, select the L7 option:
   • HTTP - select the HTTP method from the list, and the URL path. You can select more than one method.

- *Kafka *- select the message topics, by name from the list (or enter a name manually), and the action (Read or Write). You can select more than one topic or action. 

- *any *- this option does not apply any L7 filtering  in the rule

6. Click NEXT to move to STEP 4.
7. Select the Rule Properties. This the action to be taken when the rule is triggered. These are the same choices as for a regular connection rule, Allow, Detect, or Block (see Connection Policy).
8. Click FINISH.