The GitLab Kubernetes Agent provides a secure connection between a GitLab instance and a Kubernetes cluster, and allows pull-based deployments to receive alerts based on the network policies. We released the first version of the GitLab Kubernetes Agent (“the Agent”) back in September on self-managed GitLab instances. We are happy to announce that the Agent is available on GitLab SaaS, GitLab.com, and has many more features coming soon.

If you run into any issues with the GitLab Kubernetes Agent or would like to provide feedback, please, contribute in the GitLab Kubernetes Agent epic.

Why a new era?

Before, the recommended way to attach a cluster to GitLab was to provide the cluster certificates and to open up the Kube API to GitLab.com. To get the most out of the integrations, we recommended attaching the cluster with cluster-admin rights, so GitLab could provision new namespaces and create review apps. But many users found this to be overly risky and instead rolled out custom integrations that were often built around the GitLab Runner. We want to simplify and support security-minded users with the GitLab Kubernetes Agent and provide them with a safe, reliable and future-proof integration solution between GitLab and their clusters. The GitLab Kubernetes Agent provides a secure connection between the cluster and GitLab. Access rights can be controlled with the Agent more tightly by our users, and we consider it to be the basis for future Kubernetes integrations with GitLab.

#kubernetes #gitlab