Skip to content

Extend Scheduled Scan Execution Policy to enforce scans on agents

Why are we doing this work

We want to allow customers to collect vulnerabilities from images in running Kubernetes clusters that are connected with GitLab through Kubernetes Agent, so they can understand their current security risk for images that were deployed without providing sensitive data to connect to the cluster.

You can find more about our motivation to work on this issue here.

This issue is about extending Scheduled Scan Execution Policy to support Cluster Image Scanning scan for agents. In %14.3 we have introduced similar functionality, but for clusters. Customer will be able to schedule a security scan of running containers on selected time and select which namespace and resource names should be scanned. The policy will look like the following:

scan_execution_policy:
  name: Run Cluster Image Scan
  description: This policy enforces container scans against a production cluster on a daily basis.
  enabled: true
  rules:
  - type: schedule
    agents:
      agent-name:
        namespaces: []
    cadence: 0 0 * * *
  actions:
  - scan: cluster_image_scanning

namespaces may optionally be provided in order to limit the scan to the given namespaces. If omitted, then all namespaces will be scanned.

Relevant links

Non-functional requirements

  • Documentation: add documentation to doc/user/application_security/policies/index.md with information how to configure policy to enforce scan with agents, (revert !91075 (merged))
  • [-] Feature flag: no feature flag is needed as this is something that users will optionally select by including the GitLab CI template
  • [-] Performance:
  • Testing:
    • Test if you can configure policy to run on clusters connected through Kubernetes agent,

Implementation plan

Use the GitOps module as an implementation reference.

  1. Add a server package to internal/module/starboard_vulnerability which implements a GetSecurityPoliciesToSynchronize rpc.
    1. The server will poll the security policy API, checking for changes to the policies
    2. If the server returns 404, then it should be assumed that security policies are not available, but polling should continue.
    3. If there is an update available, send the new policies in the response to agentk (using new rpc objects in internal/module/starboard_vulnerability/rpc)
  2. In internal/module/starboard_vulnerability/rpc, create a PoliciesToSyncronizeWatcher, which receives a gRPC request and a callback function to call with the returned data
    1. The watcher will use the auto-generated (via protobuf) gRPC client in order to poll KAS and send any received policies to the callback function
  3. In internal/module/starboard_vulnerability/agent/module.go, add a loadSecurityPolicy callback function which receives *agentcfg.StarboardCF.
    1. When this function is called, the workerHolder will stop all workers and then create a new ones with the received configuration.
  4. In internal/module/starboard_vulnerability/agent, create a Syncronizer with a run method which receives new policies on a channel.
    1. When new policies are received on the channel, check if they would change the configuration currently held by the worker.
    2. If the configuration has changed, call the loadSecurityPolicy callback function.
  5. Create a new securityPoliciesWorker, which will be started alongside the existing worker. This worker will hold the loadSecurityPolicy callback as a struct field. This worker should be started even when the agent's Starboard configuration is empty. When this worker is run it will:
    1. Create a new channel to send security policies on
    2. Run the synchonizer, giving it the channel
    3. Start the watcher, passing a callback function which will send policies on the channel

This page may contain information related to upcoming products, features and functionality. It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes. Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab Inc.

Edited by Alexander Turinske