Enable KAS on self-managed source install

GitLab’s documentaition shows how to enable KAS using the gitlab.rb configuration. Since I’m using a source install, configuration is done via gitlab.yml.

I confgured the following:

production:
  gitlab_kas:
    enabled: true
    # File that contains the secret key for verifying access for gitlab-kas.
    # Default is '.gitlab_kas_secret' relative to Rails.root (i.e. root of the GitLab app).
    secret_file: /opt/gitlab/gitlab/.gitlab_kas_secret
        
    # The URL to the external KAS API (used by the Kubernetes agents)
    external_url: wss://git.jan-kohnert.de/-/kubernetes-agent/
        
    # The URL to the internal KAS API (used by the GitLab backend)
    internal_url: grpc://localhost:8153
       
    # The URL to the Kubernetes API proxy (used by GitLab users)
    external_k8s_proxy_url: https://git.jan-kohnert.de/-/kubernetes-agent/

There are no other options available in gitlab.yml. I cannot verify kas is running using gitlab-ctl status, since the command is not available on a source install.

When testing in one project, I get an error when trying to enable Cluster intgration (I understand, I need to enable this integration first to get the necessary information to install the Cluster-Part).

I’m not sure on how to enable the kas part, and verify, it’s running.

@jankoh Did you manage to configure it correctly? Because currently I have the same problem and I can’t find anywhere information on how to configure it.

Hi @piotrtrojanowski-dev,

I figured, the configuration above is only for gitlab itself. In a self-managed source install gitlab-agent will not be installed, at least not, when using the gitlab overlay within Gentoo.

I created an additional overlay for gitlab-kas, which can be used to install the KAS-part of gitlab-agent. In a systemd environment, on can then simply utilize systemctl start gitlab-kas to start the KAS-part (an init file for OpenRC is provided, too). Be aware, you need to configure KAS for your gitlab instance as well as your proxy (Apache, in my case) to allow needed traffic.

Kas’s config file is in yaml format, you need to set the hostname of your gitlab instance, the secret files created your gitlab-installation for communicating with your gitlab instance, as well as some addresses/ports the Kas processed are listening on; I also set the agent to use websockets.

Proxy settings (again: apache, nginx syntax differs) should be something like (depending on your settings in kas’s config file)

<Location /-/kubernetes-agent>
    ProxyPass ws://127.0.0.1:8150
    ProxyPassReverse ws://127.0.0.1:8150
</Location>

After all is set up and running, you can use GitLab’s interface to connect your cluster, and then install the agentk-part of gitlab-agent in your cluster (f.e. using the provided helm chart).

Let me know, if you need further information. :slight_smile:

Best, Jan