Before this commit the wrong namespace could have been used in
Prometheus queries for group-level installations.

Model.new.attributes now also returns encrypted attributes.

Model.new.attributes now also returns encrypted attributes.

This will allow to user the term managed? on
https://gitlab.com/gitlab-org/gitlab-ce/issues/56557. Managed? will be
used to distinct clusters that are automatically managed by GitLab

Deploy boards now will check for app.gitlab.com/env and
app.gitlab.com/app

Deploy boards now will check for app.gitlab.com/env and
app.gitlab.com/app

Use existing `public_url` validation to block various local urls. Note
that this validation will allow local urls if the "Allow requests to the
local network from hooks and services" admin setting is enabled.

Block KubeClient from using local addresses

It will also respect `allow_local_requests_from_hooks_and_services` so
if that is enabled KubeClinet will allow local addresses

No certificate is still accepted, but if one is provided it must
be valid. Only run validation if the certificate has changed to
avoid making existing records invalid.

Changes domain field to be on the Cluster page show, removing it from
Auto DevOps setting. Also injects the new environment variable
KUBE_INGRESS_BASE_DOMAIN into kubernetes#predefined_variables.

Migration to move the information from ProjectAutoDevops#domain
to Clusters::Cluster#domain. As well as necessary modifications to qa
selectors

Closes https://gitlab.com/gitlab-org/gitlab-ce/issues/52363

Signed-off-by: Rémy Coutable <remy@rymai.me>

Signed-off-by: Rémy Coutable <remy@rymai.me>

Many changes were also made to tests that expected this to default to
false.

Signed-off-by: Rémy Coutable <remy@rymai.me>

We do not want group level clusters to fall back to what was old
behaviour for project level clusters. So instead we will not return any
KUBE_TOKEN if we cannot find a suitable kubernetes_namespace for the
project, in the group level cluster case.

Add test cases to assert above

Having an invalid KUBECONFIG without a token in it is not helpful. This
only became possible recently now that we are creating a separate
namespace and service account (and hence token) to send to the runners.
This led to somewhat surprising results when troubleshooting
https://gitlab.com/gitlab-org/gitlab-ce/issues/53879 as I found that the
KUBECONFIG was still being passed but KUBE_TOKEN was not. These things
really should have been linked.

Furthermore now that we are also using the [presence of KUBECONFIG to
decide whether or not to run build steps in Auto
DevOps](https://gitlab.com/gitlab-org/gitlab-ce/blob/294d15be3e9497e7b67e1f9131ce9d5c0d68406c/lib/gitlab/ci/templates/Auto-DevOps.gitlab-ci.yml#L164)
I think it makes even more sense to ensure that KUBECONFIG is a complete
config if passed to a job.

Having an invalid KUBECONFIG without a token in it is not helpful. This
only became possible recently now that we are creating a separate
namespace and service account (and hence token) to send to the runners.
This led to somewhat surprising results when troubleshooting
https://gitlab.com/gitlab-org/gitlab-ce/issues/53879 as I found that the
KUBECONFIG was still being passed but KUBE_TOKEN was not. These things
really should have been linked.

Furthermore now that we are also using the [presence of KUBECONFIG to
decide whether or not to run build steps in Auto
DevOps](https://gitlab.com/gitlab-org/gitlab-ce/blob/294d15be3e9497e7b67e1f9131ce9d5c0d68406c/lib/gitlab/ci/templates/Auto-DevOps.gitlab-ci.yml#L164)
I think it makes even more sense to ensure that KUBECONFIG is a complete
config if passed to a job.

This moves all instances of `prepend EE::Something` and `include
EE::Something` in models to the last line of the corresponding model.
This pushes EE specific code further down the files, reducing the
likelihood of developers running into merge conflicts.

However, we only need to raise for project_type clusters to maintain
previous behaviour.

In all probablity this requirement to have actual_namespace came from
KubernetesService and will no longer be required soon.

Use model method as single source of truth instead of splitting between
presenter and Kubernetes model

Group clusters should not allow Project Namespace so don't show that
field input too

Remove the requirement to have actual_namespace before using kubeclient.

However, we only need to raise for project_type clusters to maintain
previous behaviour.

In all probablity this requirement to have actual_namespace came from
KubernetesService and will no longer be required soon.

Use model method as single source of truth instead of splitting between
presenter and Kubernetes model

Group clusters should not allow Project Namespace so don't show that
field input too

Remove the requirement to have actual_namespace before using kubeclient.

This removes the ability to pass in a different version. We can instead
create a new entry in the SUPPORTED_API_GROUPS hash for a different
version if need be.

This removes the ability to pass in a different version. We can instead
create a new entry in the SUPPORTED_API_GROUPS hash for a different
version if need be.

Find and replace everywhere we pass in `api_groups` to KubeClient, as no
longer needed

Find and replace everywhere we pass in `api_groups` to KubeClient, as no
longer needed