Using Caddy as a reverse proxy with authentication

[arjonbu (Arjon Bujupi)]

1. The problem I’m having:

I am running Caddy as a reverse proxy inside Kubernetes (not as an ingress controller). I want my services to be able to connect to Caddy via http internally and Caddy should do the authentication for the remote endpoints.

I want to support 2 cases. One with api-key authentication (easily done by just adding the auth header) and one for 0auth (generally testing auth0.com). Auth0 auth should be done machine to machine, and not by the user. I want to support the usual secret key + access key credentials. The normal flow for this type of auth, is to authenticate using access key + secret key and then get a token which will be used for future calls.

So the flow should be this:

internal workload ==== http ====> caddy =====authenticate=====> Remote endpoint

My application handles the host header so that part is irrelevant. I do not need any help regarding Kubernetes. The Caddy configuration should be the same even if it’s running in a VM.

3. Caddy version:

v2.8.4

4. How I installed and ran Caddy:

Shouldn’t matter. My question relates strictly to configuration. But I am running it as a simple deployment on Kubernetes.

d. My complete Caddy config:

{
  http_port 8080
  
  auto_https off
  log {
    output stdout
  }
  
}

:9999 {
  handle / {
    respond "OK"
  }
}


http://apikey.internal-domain.com {
  reverse_proxy https://api.domain.com {
    header_up Host {upstream_hostport}
    header_up api-key "MY_KEY"
  }
}

http://auth0.api.internal-domain.com {
  reverse_proxy https://api.domain.com {
    header_up Host {upstream_hostport}
    # I NEED HELP HERE
  }
}

5. Links to relevant resources:

I noticed this plugin but it seems like this can be used only when I want the user to login and protect specific paths, and not as transparent proxy which does the authentication in the background.

[francislavoie]

Are you looking for forward_auth (Caddyfile directive) — Caddy Documentation ? This directive would let you forward the request to some upstream which can check the headers (cookies etc) to see if the request is allowed to proceed through the remaining Caddy routes (i.e. reverse_proxy).

[arjonbu (Arjon Bujupi)]

Not really.

I want the Caddy virtualhost to do the authentication automatically.

So user connects to Caddy via http with no auth, then caddy will establish authentication with the remote endpoint https://example.com.

This means that the user doesn’t need credentials to connect to https://example.com

With API-keys this is easy, I just add a header “api-key” in the reverse proxy config.

http://apikey.internal-domain.com {
  reverse_proxy https://api.domain.com {
    header_up Host {upstream_hostport}
    header_up api-key "MY_KEY"
  }
}

For more complicated authentication like Auth0, I don’t know how to do it.

http://auth0.api.internal-domain.com {
  reverse_proxy https://api.domain.com {
    header_up Host {upstream_hostport}
    # I NEED HELP HERE
  }
}

[Whitestrake (Matthew Fay)]

I don’t know if any of us can help you here without knowledge of how Auth0 works.

What does it need from the client in order to authenticate?

[arjonbu (Arjon Bujupi)]

It’s OIDC machine to machine connections.

Basically you have access key and a secret key. You use these creds to get a token and then the token is used for future calls.

[Whitestrake (Matthew Fay)]

For this, I guess Caddy would have to act independently as its own OIDC client on behalf of users? I’m pretty sure we have nothing like this built in to Caddy. You’d have to look at a plugin.

Looks like there’s options you might use to build a plugin, like GitHub - coreos/go-oidc: A Go OpenID Connect client. and oauth2 package - golang.org/x/oauth2 - Go Packages, maybe. A custom handler could be written to maintain a valid token and inject it into proxied requests.

I have to admit this seems really strange to me, though. Why not simply turn off authentication for the API? Or disable that authentication for the Caddy IP?