feat(auth): optionally deploy OpenShift OAuth Proxy #127
Conversation
|
Not sure if I'm missing something obvious but with this setup, the OpenShift login redirect flow works and the user can get into the Cryostat Web UI, load all the assets, and make normal HTTP requests. However, the WebSocket connection to the server fails with an |
|
Example of such an access log line: |
|
|
|
I also tried with a rebuild of the oauth-proxy using golang 1.22.1, but it looks the exact same. |
… basic auth is not configured, go directly to OpenShift SSO
|
Other than the WebSocket bug, which I'm pretty well convinced is another openshift-oauth-proxy bug, I think this PR is basically complete. |
|
If I apply the same interceptor trick to the oauth-proxy rebuild that I did here: openshift/oauth-proxy#272 (comment) this causes the proxy to simply pass all requests without actually requiring any authz (no OpenShift redirect etc.), and it also allows the frontend to properly establish its WebSocket connection with the backend via the proxy. That seems to confirm that this is a proxy bug. |
|
Aha: openshift/oauth-proxy#157 Let me try this. |
|
Ha. That's incredibly silly.
|
|
@ebaron I remember discussing at some point before an idea about unifying the OpenShift SSO support and Route support into one "OpenShift integration" flag, or more generally something like a |
| @@ -300,5 +270,11 @@ spec: | |||
| {{- if .Values.authentication.basicAuth.enabled }} | |||
| - name: {{ .Release.Name }}-htpasswd | |||
| secret: | |||
| defaultMode: 420 | |||
There was a problem hiding this comment.
This is 0644 isn't it? Should we have something like 0440 instead?
charts/cryostat/values.yaml
Outdated
| capabilities: | ||
| drop: | ||
| - ALL | ||
| # |
There was a problem hiding this comment.
Yup, looks like it, whoops.
I think leaving them separate is fine for now. When releasing downstream, we can default them both to true. I imagine the downstream release will typically be how this Helm Chart is used on OpenShift.
It seems like the OAuth proxy expects a JSON string argument with the permissions. We could just define a default and allow the user to override it with their own JSON string. Not the most user-friendly, but the alternative I can think of is supplying a Role or ClusterRole, and at least the latter requires elevated permissions to do. |
$ cat htpasswd.conf
user:$2y$05$Ju.w7ibNuQ/xaAfKH74lJOJ5xqZbONaNWf7HnrjQuZP.4nhLrr0uS
$ oc create secret generic basicauth --from-file=htpasswd.conf
secret/basicauth created
$ helm install cryostat --set authentication.openshift.enabled=true --set core.route.enabled=true --set openshiftOauthProxy.image.repository=quay.io/andrewazores/openshift-oauth-proxy --set openshiftOauthProxy.image.tag=test-14 --set authentication.basicAuth.enabled=true --set authentication.basicAuth.secretName=basicauth --set authentication.basicAuth.filename=htpasswd.conf ./charts/cryostat/
With this, both OpenShift SSO and htpasswd Basic (
|
Replaces #126
Based on #124
Fixes #117
Not handled here: RBAC. This puts the OpenShift OAuth Proxy in front of the other containers in the Pod, but it will allow any OpenShift account (or Basic credentials if configured additionally) through. Restricting access to OpenShift accounts with particular roles/permissions is still TODO - I wonder if the required set of permissions should just be hardcoded or if this should be something that the deploying user can configure as well.