Enable Gitlab managed cluster resources through agent config file

What does this MR do and why?

This MR enables users to enable Gitlab managed cluster resources using resource_management.enabled key in the agent configuration file.

Changelog: added

References

Please include cross links to any resources that are relevant to this MR. This will give reviewers and future readers helpful context to give an efficient review of the changes introduced.

• Part of #507268 (closed)

MR acceptance checklist

Please evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.

Database review

The CiAccess finder currently searches for all agents that a given project is authorised to use. This merge request adds the option to search for authorisations that match a given agent only. The generated query is mostly unchanged, with an extra WHERE clause to filter by the agent ID.

Example queries:

• Project level: before / after
• Group level: before / after

How to set up and validate locally

Numbered steps to set up and validate the change are strongly suggested.

1. Run GDK. Stop KAS. (gdk start && gdk stop gitlab-k8s-agent)
2. Run KAS with the latest master branch in your local. (See Running Kas and agentk locally)
3. Set up a example project, and connect it to the gitlab agent. Add agent config file and allow ci_access to the agent.(Authorize the agent to access your projects) For example:

ci_access:
  projects:
    - id: path/to/project
      resource_management:
        enabled: true # This enables the resource_management

4. Add CI job .gitlab-ci.yml

deploy:
  image:
    name: bitnami/kubectl:latest
    entrypoint: ['']
  environment:
    name: env1 # Change to your environment name
    deployment_tier: staging
  script:
    - kubectl config get-contexts
    - kubectl get ns

4. Enable Feature flag in your Rails console. (Feature.enable(:gitlab_managed_cluster_resources))
5. Push commit and run a CI pipeline.
6. It will execute the Gitlab managed cluster resources. Before the CI pipeline starts, it starts the prerequisite class, that will communicate with KAS and apply environment template. The default template will create the namespace (e.g. env1-24-5) and role binding.
7. (Optionally) You can test using a customizable default template. Add a default.yaml at .gitlab/agents/<agent-name>/environment_templates/default.yaml. I tested with this and confirmed the custom name namespace was created.

objects:
  - apiVersion: v1
    kind: Namespace
    metadata:
      name: '{{ .environment.slug }}-{{ .project.id }}-{{ .agent.id }}'
  - apiVersion: v1
    kind: Namespace
    metadata:
      name: '{{ .environment.slug }}-{{ .project.id }}-{{ .agent.id }}-custom-namespace'

$ kubectl get ns | grep env
env1-24-5                        Active   8s
env1-24-5-custom-namespace       Active   8s