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 totrue
and is optional - the
ci_access.enabled
flag defaults totrue
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
- implement the base feature without the
enabled
flags - Implement a UI that shows the external agents list, including the available, not enrolled agents
- provide instructions how to enable an agent
- implement
gitops.enabled
flag - implement
ci_access.enabled
flag - still needs validation if it needs to be branch specific, out of scope for now
Further details
- We can further improve this feature by implementing #337904 (closed) in a following iteration
- Not in scope for this issue is extended authorization at the group level Agent: Create a group level authorisation syste... (#354514 - closed)