Skip to content

Use network policy egress of remote development agent

Vishal Tak requested to merge vtak/egress_agent_config_reoncile into master

What does this MR do and why?

Issue: Backend: Use agent's egress IP rules to generat... (#427236 - closed)

Use network policy egress of remote development agent

Make the workspace firewall rules dynamic by using the network policy egress rules configured for the remote development module of the agent.

How to set up and validate locally

Numbered steps to set up and validate the change are strongly suggested.

  1. Configure an agent with the following configuration

    remote_development:
  enabled: true
  network_policy:
    enabled: true

  2. Create a new workspace. This workspace would be reported as Failed.

  3. Verify the logs of the workspace in Kubernetes

    # change the namespace to the workspace's namespace
kubens EXAMPLE

# get the pods
kubectl get po  

# this pod should not be in a `Running` status
# check the logs
kubectl logs -f POD_NAME -c gl-cloner-injector-gl-cloner-injector-command-1

    The logs should be alongs the lines of the following

    Cloning into '/projects/gitlab-ui-private'...
fatal: unable to access 'http://gdk.test:3000/gitlab-org/gitlab-ui-private.git/': Failed to connect to gdk.test port 3000 after 3050 ms: Connection refused

    This happens because from within our workspace in Kubernetes, we are trying to access GitLab to clone the repository. This GitLab is available on a private IP which we have not allowed in our agent configuration. Let's allow it.

  4. Fetch the IP on which your gitlab is exposed. If you've setup Remote Development based on the steps in https://gitlab.com/gitlab-org/remote-development/gitlab-remote-development-docs/-/blob/main/doc/local-development-environment-setup.md#setup-gdk-ga4k-gitlab-agent-for-kubernetes-and-remote-development-configuration , your GDK(GitLab) shoudl be exposed on 172.16.123.1.

  5. Configure an agent with the following configuration

    remote_development:
  enabled: true
  network_policy:
    enabled: true
    egress:
    - allow: '0.0.0.0/0'
      except:
      - '10.0.0.0/8'
      - '172.16.0.0/12'
      - '192.168.0.0/16'
    - allow: '172.16.123.1/32'

  6. Create a new workspace from GitLab.

  7. Verify that the Network Policy generated in Kubernetes for this workspace has the correct egress rules that we configured above - kubectl get networkpolicy -A

  8. Verify that the workspace is in a Running state.

MR acceptance checklist

This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.

Edited by Alper Akgun

Merge request reports