Integrate Fairwinds Polaris w/ GitLab Kubernetes Agent

Release notes

Having well defined and automated policies around what and how is being deployed into your Kubernetes clusters is a key requirement to build a stable, scalable platform and enable self-service of development teams. To help platform teams around setting up the required policies, GitLab now ships with Polaris support. If you connect your Kubernetes clusters to GitLab with the GitLab Kubernetes Agent, the Agent can intercept Polaris policy violations and warnings and raise related incidents inside GitLab.

This feature was developed together with Fairwinds, the primary developers behind the open source Polaris tool.

Topic

Per discussion with @nagyv-gitlab we'd like to integrate Polaris with the GitLab Kubernetes Agent.

Possible paths here:

  • Create issues when Polaris finds a policy violation in the cluster
  • Show live Polaris results in the GitLab UI
  • Run Polaris as an Admission Controller
  • Add Polaris output to merge requests similar to other scanner outputs

Proposal

What if we integrate the validation logic into the agent itself? I didn't want to do it for the reasons, described in other comments above (dependency hell, lack of clear segregation of failure and responsibility domains), but if we move it into a separate process/binary, then these are mitigated. Benefits:

  1. Continuous validation and enforcement of Polaris policies. Policies are configured in the agent's configuration repo as part of agent's configuration.
  2. Policies are configured by the agent owner. Owner != user, performing the write. They may be from different teams - platform operator and application developer.
  3. Only applies to GitOps and access via CI tunnel (&5528). It's trivial to attribute a warning or a rejection to a particular project.
  1. the source for the Polaris webhook and Polaris validation logic implementation still lives in a Fairwinds repo, not a GitLab repo
  2. the Polaris executable could still be a stock binary build (well, after making any upgrades to its source we might need to play nice with gitlab-agent)
  3. something on the gitlab-agent side (and therefore gitlab side) decides what GitLab project/repo id is involved, and what (if any) issue/incident/alert creator id will be used.
  4. something on the gitlab-agent side (or gitlab) is responsible for creating any GitLab users/identities needed, for a project/repo, for use as issue creators, for issues caused by Polaris findings
  5. any such GitLab-specific needed config will be passed to Polaris either (1) by config readable at polaris startup, and/or (2) embedded in annotations/labels on the k8s API requests (or involved k8s resources) that descend into the Polaris webhook/validation, and/or (3) passed in params in any "side channel" calls made from agentk to polaris (ie. if polaris exposes a new gRPC API for agentk to query)
  6. any Polaris-specific behavior gitlab-agent needs we'll try to keep in the code for a new polaris-specific gitlab-agent "internal module" (and respect the current kas vs agentk side breakout) (eg. gitlab-agent code to launch "G2"-style polaris instances as needed, as described below in G2)
  7. we can start with just logging it in a particular agent's log. We intend to have an activity stream of events, coming from each agent, displayed on a dashboard (#277323 (closed)). Once we have it, we'll just put alerts/rejections there. In that UI ^ we can have a button to create an issue for a warning/rejection. That'd be consistent with our security dashboards.

Open questions

  1. do you mean something like: (1) we'd be running a persistent "polaris webhook" process (registered with k8s), or (2) agentk just executes one-off program invocations of polaris (so it causes transient polaris processes, only on demand) for each validation request need?

I see attractions of G1 and G2. but I think I prefer G2. I think you also meant G2?

Edited by Viktor Nagy (GitLab)