Doc request: Describe how to protect the knative broker to be accessed from selected namespaces

[matzew]

With Istio we could restrict the access to the Knative Broker, using the AuthorizationPolicy so that we can allow a number of workloads/namespaces to access different Broker URLs.

[matzew]

Below is a suggested content. But I am not sure where exactly to place this? Admin vs Dev ? or mix?

---

Namespace authorization for the Knative Broker with Istio

This guide shows how to authorize workloads from selected namespaces for accessing the Knative Kafka Broker.

Before you begin

You need:

• knative eventing
• https://knative.dev/docs/install/installing-istio/

Prepare the broker

In order have Istio being able to handle JWT-based user authentication the knative-eventing namespace needs to be labeld:

kubectl label namespace knative-eventing istio-injection=enabled

And the pod for the broker-ingress needs to be restarted, so it does get the istio-proxy container injected as the sidecar:

kubectl delete pod mt-broker-ingress-57db965447-jkl2k -n knative-eventing 

We now see that the pod has two containers:

knative-eventing     mt-broker-ingress-57db965447-jxzfk           2/2     Running   1              175m

Create a Broker

Create a broker, like:

apiVersion: eventing.knative.dev/v1
kind: Broker
metadata:
  namespace: default
  name: my-broker

get the URL from the broker:

kubectl get broker -A 
NAMESPACE   NAME        URL                                                                          AGE   READY   REASON
default     my-broker   http://broker-ingress.knative-eventing.svc.cluster.local/default/my-broker   6s    True    

Start a curl pod:

kubectl -n default run curl --image=radial/busyboxplus:curl -i --tty

Send a CloudEvent with an HTTP Post against the broker URL

curl -X POST -v \
    -H "content-type: application/json"  \
    -H "ce-specversion: 1.0"  \
    -H "ce-source: my/curl/command"  \
    -H "ce-type: my.demo.event"  \
    -H "ce-id: 0815"  \
    -d '{"value":"Hello Knative"}' \
    http://broker-ingress.knative-eventing.svc.cluster.local/default/my-broker

The curl is exectued in the default namespace and the server does return a 202 HTTP response code, which means that the broker did accept the request:

...
* Mark bundle as not supporting multiuse
< HTTP/1.1 202 Accepted
< allow: POST, OPTIONS
< date: Tue, 15 Mar 2022 13:37:57 GMT
< content-length: 0
< x-envoy-upstream-service-time: 79
< server: istio-envoy
< x-envoy-decorator-operation: broker-ingress.knative-eventing.svc.cluster.local:80/*

Restrict the access to the broker

Now we apply a AuthorizationPolicy in the knative-eventing namespace to describe that the path to the my-broker object is limited to workloads that are running in the bar namespace:

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: require-jwt
  namespace: knative-eventing
spec:
  action: ALLOW
  rules:
  - from:
    - source:
        namespaces: ["bar"]
    to:
    - operation:
        methods: ["POST"]
        paths: ["/default/my-broker"]

Now retrying the curl example in the default namespace from above will result in a 403 - Forbidden response code from the server, that the RBAC access was denied:

* Mark bundle as not supporting multiuse
< HTTP/1.1 403 Forbidden
< content-length: 19
< content-type: text/plain
< date: Tue, 15 Mar 2022 14:53:46 GMT
< server: istio-envoy
< connection: close
< x-envoy-decorator-operation: broker-ingress.knative-eventing.svc.cluster.local:80/*
< 
* Closing connection 0
RBAC: access denied

Prepare the application namespace

In order get the AuthorizationPolicy working, we need to create the bar namespace and also label it:

kubectl create ns bar  
kubectl label namespace bar istio-injection=enabled 

Start a curl pod inside of the bar namespace:

kubectl -n bar run curl --image=radial/busyboxplus:curl -i --tty

You will see there are two pods, one for the curl and the other one is for the istio-proxy:

kubectl get pods -nbar             
NAME   READY   STATUS    RESTARTS   AGE
curl   2/2     Running   0          39s

Now apply the same curl command from the pod that is running in the bar namespace and a 202 - Accepted is being returned:

< HTTP/1.1 202 Accepted
< allow: POST, OPTIONS
< date: Tue, 15 Mar 2022 15:08:57 GMT
< content-length: 0
< x-envoy-upstream-service-time: 84
< server: envoy

[github-actions]

This issue is stale because it has been open for 90 days with no
activity. It will automatically close after 30 more days of
inactivity. Reopen the issue with /reopen. Mark the issue as
fresh by adding the comment /remove-lifecycle stale.

[abrennan89]

Looks like a duplicate of #4824

[matzew]

/reopen

this is not a duplicate of 4824 - I created both, since they cover different use-cases

[knative-prow]

@matzew: Reopened this issue.

In response to this:

/reopen

this is not a duplicate of 4824 - I created both, since they cover different use-cases

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.