Extend Scheduled Scan Execution Policy with Cluster Image Scanning scan
Why are we doing this work
We want to allow customers to collect vulnerabilities from images in running Kubernetes clusters so they can understand their current security risk not only for images that are scanned as a part of CI Pipeline, but also for images that were deployed without using GitLab CI.
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. 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 namespaces
, resources
, kinds
, and containers
fields in policy configuration should be optional. When the user does not provide them, we should fetch all found vulnerabilities in the cluster:
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
clusters:
production:
namespaces:
- production
- staging
resources:
- nginx
- knative
containers:
- nginx
- knative
kinds:
- deployment
cadence: 0 0 * * *
actions:
- scan: cluster_image_scanning
Relevant links
Non-functional requirements
-
Documentation: add documentation to doc/user/application_security/policies/index.md
with information how to configure policy to use this analyzer, - [-] 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 ,
- Test if vulnerabilities from security report from
cluster_image_scanning
analyzer are visible in database
Implementation plan
-
backend extend ee/app/validators/json_schemas/security_orchestration_policy.json
with new action scan typecluster_image_scan
and check ifnamespaces
,resources
,kinds
, andcontainers
fields are valid when provided (both are optional for this new scan type), -
backend extend ee/lib/gitlab/ci/config/security_orchestration_policies/processor.rb
with logic to extend config whencluster_image_scan
is provided in policy (you could create new service similar to Security::SecurityOrchestrationPolicies::OnDemandScanPipelineConfigurationService to prepare the job configuration), -
backend extend process_action
method inee/app/services/security/security_orchestration_policies/rule_schedule_service.rb
to support new scancluster_image_scan
and start new pipeline withCluster Image Scan
job only (create new service to manage that, likeDastOnDemandScans::CreateService
), -
backend create new service Security::SecurityOrchestrationPolicies::CreatePipelineService
that will be responsible for starting new pipeline with selected security scan. In this new service we will create and start new pipeline:
Ci::CreatePipelineService
.new(project, current_user, ref: branch)
.execute(:security_orchestration_policy, content: ci_yaml)
-
backend extend self.sources
method inapp/models/concerns/enums/ci/pipeline.rb
with new value:security_orchestration_policy: 14
, addsecurity_orchestration_policy
to slice arguments inself.dangling_sources
method, -
backend extend dangling_build?
method inlib/gitlab/ci/pipeline/chain/command.rb
withsecurity_orchestration_policy
, -
backend remember to send values of namespaces
andresources
fields to job configuration and make sure that analyzer receives and uses these values to properly fetch vulnerabilities from the cluster whenever we are configuringcluster_image_scan
job