envoyExtAuthzHttp to https oauth2-proxy

Security
1

Hi,

I’d like to externalize oauth2-proxy and expose it with https.

How could I configure envoyExtAuthzHttp service to a https url?

Something like this below but it does not work…

meshConfig:
    extensionProviders:
      - name: "oauth2-proxy"
        envoyExtAuthzHttp:
          service: "https://my-oauth2-proxy.my-domain.com"
          port: "443"
         ...

I need that cause oauth2-proxy is deployed on one cluster but I have multiple clusters on multiple regions that all talk to the single oauth2-proxy…

2

Hey buddy! I’m working with OAuth2 Proxy as an external authorizer as well.

I think that the external authorizer definition in meshConfig requires that your oauth2-proxy are in the same cluster. It’s just my opinion about what I learned in the last days.

So, I didn’t understand your use case. Why you need the same oauth2-proxy for all clusters? In my solution here we have each cluster with your own oauth2-proxy and all these oauth2-proxies integrate with our single keycloak.

Could you explain more your use case to think about how I can help you. :slight_smile:

3

Hey @DougTrajana, thanks for the quick reply.

I don’t have the opportunity to have an oauth2-proxy in each cluster as I don’t have the hand on Okta. So Okta has a single callback url to the single expose oauth2-proxy, ie istio-auth.my-domain.com.

Having a “https://…” service in meshConfig gave me an error (service not part of Istio registry) so I created a ServiceEntry like this:

apiVersion: networking.istio.io/v1alpha3
kind: ServiceEntry
metadata:
  name: oauth-proxy-external
  namespace : istio-system
spec:
  hosts:
  - istio-auth.my-domain.com
  location: MESH_EXTERNAL
  ports:
  - number: 443
    name: https
    protocol: HTTPS
  resolution: DNS

And use the ServiceEntry host

meshConfig:
    extensionProviders:
      - name: "oauth2-proxy"
        envoyExtAuthzHttp:
          service: "istio-auth.my-domain.com"
          port: "443"
         ...

But now instead of having a simple “RBAC : Access denied” message on the browser I have a simple 403 and no logs in oauth2-proxy so it’s never reached.

BTW, when in the cluster where oauth2-proxy resides and setting the envoyExtAuthzHttp service to the internal DNS of the svc, it works. But then it works only on the one cluster with oauth2-proxy, not the others.

4

Awesome, your external authorizer seems to be ok. Do you define an AuthorizationPolicy with custom action to call this external authorizer?

5

Yes, otherwize I could not make it work when using internal DNS name of the oauth2-proxy.

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: istio-gateway-oauth-proxy
  namespace: istio-system
spec:
  action: CUSTOM
  provider:
    name: oauth2-proxy-provider
  rules:
    - to:
        - operation:
            paths:
              - '*'
  selector:
    matchLabels:
      istio: secured-ingressgateway

The issue occurs when I change envoyExtAuthzHttp service from oauth2-proxy.istio-system.svc.cluster.local to istio-auth.my-domain.com

Thanks for your help :wink:

6

I created a ticket on Istio github : External Authorization outside of the mesh · Issue #33595 · istio/istio · GitHub with a lot of details

7

The provider.name doesn’t match with the name that you defined in extensionProviders.name. Try something like that:

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: istio-gateway-oauth-proxy
  namespace: istio-system
spec:
  action: CUSTOM
  selector:
    matchLabels:
      istio: secured-ingressgateway
  provider:
    name: oauth2-proxy
  rules:
    - {}
8

My bad, poor copy pasting… the actual AuthorizationPolicy is

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: istio-gateway-oauth-proxy
  namespace: istio-system
spec:
  action: CUSTOM
  provider:
    name: oauth2-proxy
  rules:
    - to:
        - operation:
            paths:
              - '*'
  selector:
    matchLabels:
      istio: secured-ingressgateway

So this is not the source of the issue.

As I said earlier, it works correctly when using the internal DNS name of the oauth2-proxy service, it’s when I use the external DNS name of oauth2-proxy that it fails…

IMHO, ext_authz cannot talk to an https service…