0

Weird things are happening !

I've got a Keycloak and a simple Httpbin application in my cluster.

I've setup Istio to authentificate users using keycloak (as described in the Istio documentation)

apiVersion: "authentication.istio.io/v1alpha1"
kind: "Policy"
metadata:
  name: auth-token
spec:
  targets:
    - name: httpbin
  origins:
    - jwt:
        issuer: "http://10.233.11.203/auth/realms/istio"
        jwksUri: "http://10.233.11.203/auth/realms/istio/protocol/openid-connect/certs"
  principalBinding: USE_ORIGIN

With the following configuration setup when I try : 

curl <IP_OF_HTTPBIN>

I get Origin authentification failed which is totally normal as I have not provided any access token.

Now when I use my web browser to access the application I would expect some kind of error but NO it works...

My problem is that it should not work. The browser is not MORE authorised then the curl command was...

For information I access the application from my browser using kubectl port-forward and a reverse proxy.

Doctor
  • 7,115
  • 4
  • 37
  • 55

2 Answers2

1

kubectl port-forward forwards traffic from your machine's localhost directly to a k8 pod, bypassing all Istio authentication. When your run curl against httpbin's public ip, the request is handled by Istio's gateway and the jwt token validated.

Istio's jwt validation happens downstream and independent of your pod. If you hit your pod directly, you are intentionally bypassing end user authentication for development purposes. This lets you develop services independent of how they are authenticated.

James Conkling
  • 3,235
  • 2
  • 25
  • 37
  • Thx for your answer ! I get that going through the gateway let's Istio deal with the security. But what I still don't understand is the difference between curling the cluster IP and using port-forward. In your first paragraph you compare *port-forward* with *curling* **through the gateway**. But my interogation is about the differences between *port-forward* and *curl* using cluster IP directly **(without the gateway)**. Though maybe I didn't get what you meant :-p – Doctor May 13 '19 at 13:18
  • What I understand for now is that you cannot expect the same result connecting from outside than using the Kubernetes API, since you are actually connecting directly to the pod. There is more info on this stack thread[1]. _____________ [1]:https://stackoverflow.com/questions/51468491/how-kubectl-port-forward-works – Lozano May 16 '19 at 11:17
0

I found a way to fix this... If I use a gateway to access the application then the browser also gets the Origin authentification failed.

But this doesn't explain why in the first place the browser is bypassing istio's policy and curl doesn't...

Doctor
  • 7,115
  • 4
  • 37
  • 55