[pkg] add env var to dashboard deplyoment for kubernetes oidc auth

[dymart]

What does this PR do?

Allow for non dex oidc auth providers in managed kubernetes deployments by setting env vars in che-dashboard deployment if present. Currently che-dashboard has no way to change these variables so no way to us non dex auth. With these changes it will be possible to set all of these env vars from CheCluster. Making it easier to use che with managed kubernetes.

Add CHE_INFRA_KUBERNETES_PORT, CHE_INFRA_KUBERNETES_PORT_443_TCP_ADDR, CHE_INFRA_KUBERNETES_PORT_443_TCP, CHE_INFRA_KUBERNETES_SERVICE_HOST to the che-dashboard deployment for kubernetes if the variables are set.

spec:
  components:
    cheServer:
      extraProperties:
        CHE_INFRA_KUBERNETES_PORT:
        CHE_INFRA_KUBERNETES_PORT_443_TCP_ADDR:
        CHE_INFRA_KUBERNETES_PORT_443_TCP: 
        CHE_INFRA_KUBERNETES_SERVICE_HOST:

This way non dex oidc auth providers can be used ( ex: gke with external auth). This significantly simplifies deployment and can make auth consistent and easy to use with managed kubernetes clusters where the kube api cannot be set or changed.

These are then used as env vars in the che-dashboard deployment for kubernetes. With changes to the dashboard in another pr (eclipse-che/che-dashboard#596 ), if these env vars are present in the deployment the dashboard will use them to set KUBERNETES_PORT, KUBERNETES_PORT_443_TCP_ADDR, KUBERNETES_PORT_443_TCP, KUBERNETES_SERVICE_HOST. Allowing for the configuration of a non dex oidc auth provider.

What issues does this PR fix or reference?

eclipse-che/che#21260

How to test this PR?

Test platform: managed kubernetes with non dex oidc auth.

cat EOF << > /tmp/patch.yaml
spec:
  components:
    cheServer:
      extraProperties:
        # needed but not added in this pr
        CHE_INFRA_KUBERNETES_MASTER__URL=https://gke-oidc-envoy.anthos-identity-service
        # added in this pr
        CHE_INFRA_KUBERNETES_PORT:tcp://<gke-oidc-envoy LB IP>:443
        CHE_INFRA_KUBERNETES_PORT_443_TCP_ADDR:<gke-oidc-envoy LB IP>
        CHE_INFRA_KUBERNETES_PORT_443_TCP:tcp://<gke-oidc-envoy LB IP>:443
        CHE_INFRA_KUBERNETES_SERVICE_HOST:<gke-oidc-envoy LB IP>
EOF

chectl server:deploy \
     --installer operator \
     --platform k8s \
     --che-operator-image <CUSTOM_OPERATOR_IMAGE> \
     --che-operator-cr-patch-yaml /tmp/patch.yaml

Docs pr: eclipse-che/che-docs#2413

PR Checklist

As the author of this Pull Request I made sure that:

• The Eclipse Contributor Agreement is valid
• Code produced is complete
• Code builds without errors
• Tests are covering the bugfix
• Custom resource definition file is up to date
• OLM bundles are up to date
• The repository devfile is up to date and works
• Sections What issues does this PR fix or reference and How to test this PR completed
• Relevant user documentation updated
• Relevant contributing documentation updated
• CI/CD changes implemented, documented and communicated

Reviewers

Reviewers, please comment how you tested the PR when approving it.

[openshift-ci]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: dymart

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[openshift-ci]

Hi @dymart. Thanks for your PR.

I'm waiting for a eclipse-che member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[tolusha]

@dymart
Thank you for contribution.
As far as I understand, in general you need a way to mount arbitrary environment variables into Eclipse Che containers.
If so, let me open a PR to provide more common way to do so.

[tolusha]

@dymart
I found this doc which can solve your issues
https://www.eclipse.org/che/docs/stable/administration-guide/mounting-a-secret-as-a-file-or-an-environment-variable-into-a-container/#mounting-a-secret-or-a-configmap-as-an-environment-variable-into-a-container_che

@karatkep
It doesn't solve your issues, I need to provide a PR.
eclipse-che/che#21530
#1444

[dymart]

Hi @tolusha,

The potential solution you provided would not solve the problem. Being able to configure the properties through the CheCluster CR would be the best solution.

Just to clarify the problem is specifically related to che-dashboard needing these environment variables to be set and used to be able to work with a kubernetes cluster that is managed by one of the large cloud providers ( as one cannot change the kube api there). It would be one of the last hurdles to allow che to run on one of the large cloud providers. ex: eclipse-che/che#21304

The issues you reference as similar seem to deal with configuring oauth proxy and allowing more configuration than is currently possible and while that would be very nice to have the two issue may be of different severity. The issue this pr resolves renders che unusable on kubernetes cluster that are managed by cloud providers like gke. Allowing this would enable others to install che on these could providers as well.

Please also consider that others would like to use this functionality in the mean time as a more general solution is being worked on. I understand that reworking this might not be a priority for the project currently and that this current solution may not be as general as you would like but it would be a simple and clean solution that could easily be removed when the project has time to implement a more general solution.

thanks

[tolusha]

@dymart

Being able to configure the properties through the CheCluster CR would be the best solution.

Pls have a look at [1] and comment if needed. I've already started working on this issue and I will provide a PR soon.
[1] eclipse-che/che#21605

[tolusha]

#1468

[dymart]

Great,

thank you @tolusha that pr looks great!

Really appreciate it, just didn't want this issue to get backlogged for a long time. Sorry if my last message came across poorly.