Kafka with OPA

[mint-lmc]

Hi,
I am trying to test Kafka authorization flow running on Kubernetes with Strimzi, I want to produce and consume to Kafka topics from an external python clients using mTLS for the authentication and OPA for the authorization.
The authentication is working fine.
But the authorization is always denied with OPA ,
The policies are loaded from configmap :

package kafka.authz
default allow = false

allow = true {
    input.action.operation == "WRITE"
    input.requestContext.securityProtocol = "SSL"
    input.action.resourcePattern.name == "mytopic"
    input.action.resourcePattern.resourceType == "TOPIC"  
    input.requestContext.principal.name == "user1"
    input.requestContext.header.name.clientId == "user1"
}
allow = true {
    allowedActions :=  ["DESCRIBE", "READ"]
    input.action.operation == allowedActions[_]
    input.requestContext.securityProtocol = "SSL"
    input.action.resourcePattern.name == "mytopic"
    input.action.resourcePattern.resourceType == "TOPIC"  
    input.requestContext.principal.name == "user2"
    input.requestContext.header.name.clientId == "user2"
}

OPA response :

... level":"info","msg":"Sent response.","req_id":1009,"req_method":"POST","req_path":"/v1/data/kafka/authz/allow","resp_body":"{\"decision_id\":\"c636ce37-1449-456b-a407-ad65ba97cf95\",\"result\":false}\n","resp_bytes":70,"resp_duration":0.478638,"resp_status":200, ...

It works only with an OPA policy that allows all requests:

package kafka.authz
allow := true

OPA response :
... ,"level":"info","msg":"Sent response.","req_id":5100,"req_method":"POST","req_path":"/v1/data/kafka/authz/allow","resp_body":"{\"decision_id\":\"7bc43c0e-b518-4051-b71e-03a6e9774e52\",\"result\":true}\n","resp_bytes":69,"resp_duration":0.478707,"resp_status":200, ...

Any help on how to use TLS with OPA ?

[anderseknert]

Hi there 👋 It's hard to say without seeing the actual input sent to OPA. Could you provide that here? Since you have decision logging enabled, the input should be in your decision logs. Most likely there is a difference in your expectations of the input structure vs. what is actually provided.

[mint-lmc]

Hi @anderseknert ,

The input was stored in configmap with the policies :

{
  "action": {
    "logIfAllowed": true,
    "logIfDenied": true,
    "operation": "WRITE",
    "resourcePattern": {
      "name": "mytopic",
      "patternType": "LITERAL",
      "resourceType": "TOPIC",
      "unknown": false
    },
    "resourceReferenceCount": 1
  },
  "requestContext": {
    "clientAddress": "/10.42.0.1",
    "clientInformation": {
      "softwareName": "unknown",
      "softwareVersion": "unknown"
    },
    "connectionId": "10.42.0.66:9095-10.42.0.1:35192-18",
    "header": {
      "headerVersion": 1,
      "name": {
        "clientId": "user1",
        "correlationId": 9,
        "requestApiKey": 3,
        "requestApiVersion": 1
      }
    },
    "listenerName": "SSL",
    "principal": {
      "name": "CN=user1",
      "principalType": "User"
    },
    "securityProtocol": "SSL"
  }
}

And bellow is the decision logs:

{"client_addr":"10.42.0.66:54620","level":"info","msg":"Received request.","req_body":"{\"input\":{\"requestContext\":{\"clientAddress\":\"/10.42.0.1\",\"clientInformation\":{\"softwareName\":\"unknown\",\"softwareVersion\":\"unknown\"},\"connectionId\":\"10.42.0.66:9095-10.42.0.1:11310-19\",\"header\":{\"name\":{\"clientId\":\"user1\",\"correlationId\":8,\"requestApiKey\":3,\"requestApiVersion\":1},\"headerVersion\":1},\"listenerName\":\"EXTERNAL-9095\",\"principal\":{\"principalType\":\"User\",\"name\":\"CN=user1\"},\"securityProtocol\":\"SSL\"},\"action\":{\"resourcePattern\":{\"resourceType\":\"TOPIC\",\"name\":\"mytopic\",\"patternType\":\"LITERAL\",\"unknown\":false},\"operation\":\"DESCRIBE\",\"resourceReferenceCount\":1,\"logIfAllowed\":true,\"logIfDenied\":true}}}","req_id":142,"req_method":"POST","req_params":{},"req_path":"/v1/data/kafka/authz/allow","time":"2023-02-27T17:06:11Z"}
{"decision_id":"2dda817b-9799-456a-9a2a-58e0fd7cdbe9","input":{"action":{"logIfAllowed":true,"logIfDenied":true,"operation":"DESCRIBE","resourcePattern":{"name":"mytopic","patternType":"LITERAL","resourceType":"TOPIC","unknown":false},"resourceReferenceCount":1},"requestContext":{"clientAddress":"/10.42.0.1","clientInformation":{"softwareName":"unknown","softwareVersion":"unknown"},"connectionId":"10.42.0.66:9095-10.42.0.1:11310-19","header":{"headerVersion":1,"name":{"clientId":"user1","correlationId":8,"requestApiKey":3,"requestApiVersion":1}},"listenerName":"EXTERNAL-9095","principal":{"name":"CN=user1","principalType":"User"},"securityProtocol":"SSL"}},"labels":{"id":"716e2a23-3829-4d97-92a6-b123fea45a97","version":"0.49.2"},"level":"info","metrics":{"counter_server_query_cache_hit":1,"timer_rego_input_parse_ns":105129,"timer_rego_query_eval_ns":120306,"timer_server_handler_ns":270272},"msg":"Decision Log","path":"kafka/authz/allow","req_id":142,"requested_by":"10.42.0.66:54620","result":false,"time":"2023-02-27T17:06:11Z","timestamp":"2023-02-27T17:06:11.614581825Z","type":"openpolicyagent.org/decision_logs"}
{"client_addr":"10.42.0.66:54620","level":"info","msg":"Sent response.","req_id":142,"req_method":"POST","req_path":"/v1/data/kafka/authz/allow","resp_body":"{\"decision_id\":\"2dda817b-9799-456a-9a2a-58e0fd7cdbe9\",\"result\":false}\n","resp_bytes":70,"resp_duration":0.755193,"resp_status":200,"time":"2023-02-27T17:06:11Z"}

• The input directory should be specified to the kube-mgmt container ?

[anderseknert]

The input is provided by Kafka to the plugin. kube-mgmt is not involved at all in that process :)

Looking at your policy:

input.requestContext.principal.name == "user1"

And comparing it to the input you are receiving, reveals the problem. I left out any other attributes to emphasize what.

{
    "requestContext": {
        "principal": {
            "name": "CN=user1",
        }
    }
}

[mint-lmc]

Thanks for the answer, solved.

I read that kube-mgmt can be used to discover and load policies from Kubernetes ConfigMaps, I thought the issue was in loading the input , thanks for clarifying.