What Kubernetes functionality can/must be driven though Runners, proxies, direct from GitLab?

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.