KAS restricted access
Release notes
Problem to solve
(mostly copied from @SGaist)
What is still missing is:
- Control on who is allowed to connect a cluster to the instance
- Control on where the connection is made from
From a company perspective, I would say that connecting outside components to one's GitLab instance is a dedicated responsibility hence (1). For number (2), this would be a good filter to ensure that for example only company validated infrastructure can be used.
In terms of personas, I would say that Sam and Sidney would be in charge of determining who is allowed to access this feature which would likely concern Priyanka and Ingrid. Likely the same people would determine the CIDR that would be allowed to be used. The whole set of feature would likely make the work of Alex a bit simpler.
Proposal
As part of this issue, the scope would be on restricting cluster connections by CIDR.
Not in scope
Specify the users allowed to set up a connection at the group or project level. This could likely be tackled as a follow-up of Custom Roles and Permissions (&4035)
Questions & Answers
- Is this an instance/group/project level setting?
- This should be first an instance/workspace level setting
- Later, we might allow further restrictions within the top level CIDR to be defined at the group and project levels
- For instance-level setting, could this be part of the KAS configuration?
- This would not work for SaaS where we need a workspace level setting anyway.
Intended users
Primary users:
Involved users:
Feature Usage Metrics
Initial description
Hi,I have done quite a bit of research on the topic but I could not find an answer about it.
From what I have gathered, if KAS is enabled in a GitLab instance, anybody who is maintainer or owner of a project can connect a cluster to the instance and use it once the Infrastructure checkbox is activated provided he has added the required configuration files. This can happen pretty easily for example in users' personal projects.
This means that, unless blocked at the firewall level, clusters from anywhere can be connected which could be an issue security wise.
I haven't found any setting in GitLab that might be used to manage KAS access in a more restricted fashion. For example:
- only allow agent connections from given CIDRs (for example internal corporate networks)
- only allow a list of users to access/enable the Infrastructure option and more specifically the Kubernetes one.
- disable the configuration of the option globally and only an admin can activate it for a given project (a bit like making a project public can be restricted).
For example, when using certificate based cluster connections, one needed to be an instance admin to do that but I haven't found the equivalent with Agent-K.
Is there something I may have missed on that topic ?