| Age | Commit message (Collapse) | Author |
|---|
|
When Kubernetes clusters were originally built they could only
exist at the project level, and so there was logic included
that assumed there would only ever be a single Kubernetes
namespace per cluster. We now support clusters at the group
and instance level, which allows multiple namespaces.
This change consolidates various project-specific fallbacks to
generate namespaces, and hands all responsibility to the
Clusters::KubernetesNamespace model. There is now no concept of
a single namespace for a Clusters::Platforms::Kubernetes; to
retrieve a namespace a project must now be supplied in all cases.
This simplifies upcoming work to use a separate Kubernetes
namespace per project environment (instead of a namespace
per project).
|
|
When this option is enabled, GitLab will create namespaces and service
accounts as usual. When disabled, GitLab wont create any project
specific kubernetes resources
Closes https://gitlab.com/gitlab-org/gitlab-ce/issues/56557
|
|
|
|
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.
|
|
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
|
|
|
|
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
|
|
Validate k8s CA certificate at cluster creation
See merge request gitlab-org/gitlab-ce!24990
|
|
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>
|
|
Many changes were also made to tests that expected this to default to
false.
|
|
'master'
Handle nil terminals in Clusters::Platforms::Kubernetes
Closes #55551
See merge request gitlab-org/gitlab-ce!23925
|
|
|
|
Signed-off-by: Rémy Coutable <remy@rymai.me>
|
|
Make KUBECONFIG nil if KUBE_TOKEN is nil
See merge request gitlab-org/gitlab-ce!23414
|
|
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.
|
|
|
|
|
|
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.
|
|
Find and replace everywhere we pass in `api_groups` to KubeClient, as no
longer needed
|
|
This model will be used to persist into database Kubernetes properties,
such as namespace, service account name and service account token.
|
|
|
|
Partially addresses #47424.
|
|
attr_encrypted does different things with `key` depending on what mode you are using:
1. In `:per_attribute_iv_and_salt` mode, it generates a hash with the salt:
https://github.com/attr-encrypted/encryptor/blob/c3a62c4a9e74686dd95e0548f9dc2a361fdc95d1/lib/encryptor.rb#L77.
There is no need to truncate the key to 32 bytes here.
2. In `:per_attribute_iv` mode, it sets the key directly to the password, so
truncation to 32 bytes is necessary.
Closes #47166
|
|
Fixes that make this work:
* A change in Ruby (https://github.com/ruby/ruby/commit/ce635262f53b760284d56bb1027baebaaec175d1)
requires passing in the exact required length for OpenSSL keys and IVs.
* Ensure the secrets.yml is generated before any prepended modules are
loaded. This is done by renaming the `secret_token.rb` initializer to
`01_secret_token.rb`, which is a bit ugly but involves the least impact on
other files.
|
|
Conflicts:
Gemfile.lock
|
|
|
|
|
|
|
|
including/extending it
|
|
|
|
|
|
|
|
|
|
again.
|
|
|
|
|
