Running On GKE about oauth2-proxy HOT 12 CLOSED

The way I have currently got it working is by putting the following in between the GKE ingress and the reverse proxy.

func main() {
	sp := os.Getenv("SERVER_PORT")
	if sp == "" {
		log.Fatal("empty SERVER_PORT")
	}
	t := os.Getenv("TARGET_ADDRESS")
	if t == "" {
		log.Fatal("empty TARGET_ADDRESS")
	}
	u, err := url.Parse(t)
	if err != nil {
		log.Fatal("Error parsing target", t)
	}

	r := httputil.NewSingleHostReverseProxy(u)
	r.ModifyResponse = ModifyResponse

	if err := http.ListenAndServe(":"+sp, r); err != nil {
		log.Fatal()
	}
}

// ModifyResponse modifies root statuscode if it is forbidden
func ModifyResponse(response *http.Response) error {
	p := response.Request.URL.Path
	if response.StatusCode == http.StatusForbidden && (p == "/" || p == "") {
		response.StatusCode = http.StatusOK
	}
	return nil
}

from oauth2-proxy.

The proxy outputs
127.0.0.1 - - [05/Mar/2019:15:59:09 +0000] masked GET - "/" HTTP/1.1 "GoogleHC/1.0" 403 2511 0.000. I presume the GoogleHC/1.0 is an http header and could easily be handled?

from oauth2-proxy.

GoogleHC/1.0 is the user agent string, so yes, could be handled as an exception.

I'm not a GCP user so don't know how their ingress works, is there no way to configure the health check for the service to be on a non-root URL? That should be a pretty standard ingress feature I would have thought

from oauth2-proxy.

Nope, it isn't possible to set the URL. It is very very annoying! I will build a wrapper and test it. I will also try and do the healthz endpoint. Is there anything we could actually be health checking? Possibly pinging the oauth provider?

from oauth2-proxy.

Nope, it isn't possible to set the URL. It is very very annoying!

This is quite frankly shocking... I would have thought that would be a standard feature 😞

I will build a wrapper and test it.

Sure. The alternative is to try and set the root path to return a 200 response if the user agent is GoogleHC/1.0, I don't know how complicated that would be to implement though

Is there anything we could actually be health checking?

I'm not particularly sure, I think the health endpoint just needs to respond OK to allow LBs to check the process is routable and hasn't blocked.

Possibly pinging the oauth provider?

Pinging the upstream provider doesn't seem like the right approach to me, if the upstream was down we would be deregistered from the LB and then we would just get the service unavailable page from the LB which in theory is less useful than the proxy throwing an error, I think 🤔

from oauth2-proxy.

Sure. The alternative is to try and set the root path to return a 200 response if the user agent is GoogleHC/1.0, I don't know how complicated that would be to implement though

Just http middleware that returns 200 in the case that the request is / and that the User Agent is GoogleHC/1.0?

from oauth2-proxy.

Addressed so can be closed. #110

from oauth2-proxy.

Nope, it isn't possible to set the URL. It is very very annoying! I will build a wrapper and test it. I will also try and do the healthz endpoint. Is there anything we could actually be health checking? Possibly pinging the oauth provider?

It sure does have the way to change the healthcheck path. It would read it from the readinessProbe section on your deployment behind the service. So just:

readinessProbe:
    httpGet:
        path: /healthz
        port: 80
    initialDelaySeconds: 5
    periodSeconds: 5

from oauth2-proxy.

@benfdking could you test @Blasterdick's theory and let us know the result, if it's correct I'd be tempted to remove the wrapper that was recently added as it would be unnecessary code complexity

from oauth2-proxy.

I may be wrong but I think this is still a problem though: kubernetes/ingress-gce#674.

The above referenced issue is still not resolved. The ingress only works if you create the deployments and services before you create the ingress. This makes the ingress rather fragile and inflexible. No service/deployment can be changed without having to recreate the ingress if you want to depend on @Blasterdick's configuration. In any case where you were to move a deployment/service including the proxy that the ingress is pointing to, you would have to recreate the ingress which can easily be 10 minutes of downtime.

from oauth2-proxy.

@benfdking you can manually alter the status check without redeploying the Ingress and update the deployment.
So applying this to an existing installation is not a problem.

I have done this on several existing projects. As for @Blasterdick his solution, I just point to Ping.

readinessProbe:
          httpGet:
          path: /ping
          port: 4180
          scheme: HTTP

from oauth2-proxy.

This issue has been inactive for 60 days. If the issue is still relevant please comment to re-activate the issue. If no action is taken within 7 days, the issue will be marked closed.

from oauth2-proxy.