Skip to content

Manifest projects outside of the Agent configuration project

Goal

Refine the issue.

Problem to solve

As a Platform Engineer, I want to set up an agent to be accessible for deployments of specific project/groups inside my company namespace, so that I won't block developers on deploying new projects.

Both groups and projects need to be supported.

Intended users

User experience goal

The Platform Engineer and the Application Operator should be able to use a single agent connection that is managed by the Platform Engineer and customized in a restricted way by the Application Operator.

Proposal

  • Both the main/configuration and the "child"/manifest projects are to be configured in code

The main/configuration project slug is: infra-group/agents

In the main/configuration project, the file .gitlab/agents/agent-1/config.yaml contains:

gitops:
  manifest_projects:
    - id: other-group
    - id: third-group/other-project
      paths:
        - glob: '/manifests/**/*.yaml'

The child project can be any project under other-group or it is third-group/other-project.

In the child/manifest project (for example third-group/other-project), the file .gitlab/agents/external.yaml contains:

agents:
  - project_id: infra-group/agents
    agent_name: my-agent-1
    gitops:
      enabled: true

Enabled by default

As working by default is one of our product principles, and setting the project_id, agent_name is a user action, once those are set provided functionality likely should be enabled by default.

The default value of $feature.enabled needs to be determined on a case by case basis, and clearly documented. For example, the hypothetical ci_access.enabled should probably be true by default, but a hypothetical read_secrets might need to be disabled by default.

For this above reasons:

  • the gitops.enabled flag defaults to true and is optional
  • the ci_access.enabled flag defaults to true and is optional

Allowing external functionality explicitly

We do not change the current functionality if there is no external.yaml file present. The CI/CD tunnel can be shared within the descendant group of the agent without an external.yaml file.

Every other agent access needs to be explicitly specified.

Agent specific configuration

Initially, the external.yaml file does not allow for any specific configuration. The agent needs to be configured in the agent configuration project. The external.yaml file is used exclusively to authorize kas to read manifests from the manifest project.

Future iterations might allow extending the agent configuration. This logic is still to be discussed and validated, and is not in the scope of this issue today.

Iterations proposal

  1. implement the base feature without the enabled flags
  2. Implement a UI that shows the external agents list, including the available, not enrolled agents
    • provide instructions how to enable an agent
  3. implement gitops.enabled flag
  4. implement ci_access.enabled flag - still needs validation if it needs to be branch specific, out of scope for now

Further details

Permissions and Security

Edited by Viktor Nagy (GitLab)