Move away from AuthService

[kimwnasptd]

My current understanding is that the gcr.io/arrikto oci registry will be taken down at some point*.

I can think of the following moving pieces for this process:

1. Moving away from this component for the KF 1.8 release
2. Understand whether we need to patch previous versions of Kubeflow
3. Existing installations that are using AuthService

From my current understanding there won't be any migration of the image from the side of the AuthService project.

The first information that we need is for how long will he gcr.io/arrikto registry be up. After we have this we can have more concrete next steps. Hopefully I'll have some more news on this relatively soon*.

The way that I think this play out though is that we'll need to mirror images in the Kubeflow project and do patches on some* KF installations so that the mirrored image will be used instead. And of course moving away in KF 1.8 either way.

cc @kubeflow/wg-manifests-leads @DnPlas @annajung @jbottum

[DnPlas]

Thanks @kimwnasptd, I have some questions and comments.

1. Moving away from the current Authservice implementation in the upcoming 1.8 release would mean that:

• We may need to provide steps for upgrading Kubeflow 1.7 to 1.8.
• We already have a solution for replacing Authservice, do you mind sharing details about it? What would be the impact on Kubeflow components in terms of changes in manifests and/or code?
• Would this change impact the current release timeline?

2. Mirroring the existing image and patching some KF installations - For this I'd add that only the image(s) will be kept, and not the source code, which means that we won't be giving any support or releasing new versions of them, right? Lastly, I agree on this one, though I think we have to do it regardless of how long the image registry is up.

• Have we decided how many releases back we could or want to patch?
• Have we decided which container registry we are going to push these images to?

[kimwnasptd]

@DnPlas

Moving away from the current Authservice implementation in the upcoming 1.8 release would mean that:

1. Yes we'll provide upgrade instructions on how to migrate to oauth2-proxy for users that come from a 1.6, and have AuthService in their cluster
   • I'd expect the oauth2-proxy and AuthService manifests to be completely separated, so it'll be a matter of removing AuthService manifests and applying oauth2-proxy manifests
2. The 1.8 manifests will be using a completely different component oauth2-proxy
   • There shouldn't be any differences to other components
3. I wouldn't expect it to affect the release timeline

Mirroring the existing image and patching some KF installations - For this I'd add that only the image(s) will be kept, and not the source code, which means that we won't be giving any support or releasing new versions of them, right? Lastly, I agree on this one, though I think we have to do it regardless of how long the image registry is up.

Yes, we'll just mirror the images. No further support for bugfixes on the actual component.

[tomaszstachera]

@kimwnasptd we are using Kubeflow 1.7 that is using oidc-authservice. Currently we cannot pull docker pull gcr.io/arrikto/kubeflow/oidc-authservice:e236439 image. Will it be hosted somewhere?

docker pull gcr.io/arrikto/kubeflow/oidc-authservice:e236439
Error response from daemon: unauthorized: You don't have the needed permissions to perform this operation, and you may have invalid credentials. To authenticate your request, follow the steps in: https://cloud.google.com/container-registry/docs/advanced-authentication

[juliusvonkohout]

@kimwnasptd we are using Kubeflow 1.7 that is using oidc-authservice. Currently we cannot pull docker pull gcr.io/arrikto/kubeflow/oidc-authservice:e236439 image. Will it be hosted somewhere?

docker pull gcr.io/arrikto/kubeflow/oidc-authservice:e236439
Error response from daemon: unauthorized: You don't have the needed permissions to perform this operation, and you may have invalid credentials. To authenticate your request, follow the steps in: https://cloud.google.com/container-registry/docs/advanced-authentication

If you switch to Kubeflow 1.8.1 you will have a working oidc-authservice image. The registries switched. But I strongly recommend 1.9 where we removed it altogether and switched to oauth2-proxy.

[juliusvonkohout]

Images:
  - name: gcr.io/arrikto/kubeflow/oidc-authservice
    newName: docker.io/kubeflowmanifestswg/oidc-authservice
    newTag: e236439

But this is just a workaround. Please Upgrade to Kubeflow 1.8.1/1.9