Adding here the chat/answer regards the third question made by [~lfitzgerald] in the chat now.
h4. If we use the OCP ouath how to provide an alternative for the user which is running it in Kube?
First, at all, I'd like to highlight that the in POV best approach should use the kubernetes api to setup the OAuth which should make it works for both as the following references.
* https://appscode.com/products/voyager/9.0.0/guides/ingress/security/oauth/
* https://alikhil.github.io/2018/05/oauth2-proxy-for-kubernetes-services/
* https://github.com/kubernetes/ingress-nginx/blob/master/docs/user-guide/nginx-configuration/annotations.md
However, if we move forward with the approach to use OCP oauth then we can describe in the README that is a pre-requirement install the OAuth OCP proxy in kube. See the [doc|https://github.com/openshift/oauth-proxy] which is telling that will work in both.
IMHO, we should not use OCP API at all since the Kubernetes API will keep it compatible for both, however, if we are not able to do it for some specific point of for some detail then, in the future , we can add manual steps to make work with kubernetes and/or at least ir we will be have fewer changes to be made in the project projects .
Another point is that OCP shows move forward to use the Kubernetes resources instead of their specifications in order to reach full feature parity then I am afraid that we can face a scenario where the OCP API used cannot so longer work on it as well.
For example:
bq. The long-term goal in OpenShift Container Platform is to reach full feature parity in Kubernetes deployments and switch to using them as a single object type that provides fine-grained management over applications.
REF: https://docs.openshift.com/container-platform/3.11/dev_guide/deployments/kubernetes_deployments.html#kubernetes-deployments-vs-deployment-configurations
c/c [~dffrench] |
|
