Looking to avoid any direct connections from GitLab’s SaaS world into our network, but want to use as much Kubernetes functionality as possible. Is there a breakdown of which Kubernetes functionality CAN work vs. ONLY works via locally-deployed Runners, locally-deployed proxies, and direct from GitLab’s SaaS deployment?
Using any form of integration on the GitLab service will cause the service to attempt reaching out and connecting to the cluster: Adding and removing Kubernetes clusters | GitLab
If this isn’t permitted/desirable, then you can manage just the credentials on the GitLab end, and use the CI job definitions/scripts to use kubectl commands directly.
You can use the generic Environments feature to manage deployments: Environments and deployments | GitLab, without needing to actually associate any cluster to it. These also allow you to pass arbitrary links to display on dashboards, which the server will not attempt to resolve/connect to but it could work at your local end.