Lab 5.5: Add Operational Container Security Scanning

Keyboard Time: 5 mins, Automation Wait Time: 10 mins

Scenarios: Instructor-Led, Self-Paced

Scanning Other Images In The Cluster
Operational Container Scanning is able to add security findings for images used in your cluster that are not a part of your development process and therefore do not get routinely scanned during CI of the application. This scanning currently focuses on the cluster’s images and not other aspects of cluster security. The other security scanning we’ve been configuring has explictly to do with development - this scanning is part of GitLab’s Protect stage - part of operational integrity that can be enabled via the GitLab Agent.
Target Outcomes
  1. Configure Operational Container Scanning using the GitLab Agent for Kubernetes.
  2. Examine Operational Container Scanning findings.
Troubleshooting: Operational Container Scanning
Troubleshooting Guide: Operational Container Scanning
Done By Instructor for Instructor-Led Courses
  1. Logon the cluster administration machine => Instructions for SSM Session Manager for EKS
Temporary Fix

Until 361792 is resolved, you will need to run this command in the cluster:

kubectl create serviceaccount gitlab-agent -n gitlab-agent

  1. Run the following command to tail the kubernetes agent log while deployments are happening:

    kubectl logs -f -l=app=gitlab-agent -n gitlab-agent

    Leave this view open as you will be instructed to consult it to see the deployment logging activity when the GItLab Agent pulls and processes the kubernetes manifest.

  2. Open ‘classgroup/cluster-management’

  3. In the left navigation, Click Repository => Files

  4. On the upper right of the Project page, Click Web IDE

  5. Navigate to the file .gitlab/agents/spotazuseast2-agent/config.yml

  6. Look at the minutes past the hour of the current time.

  7. Add 5 minutes and insert the following snippet - substitute your minutes number for ‘55’ in the below:

    starboard:
  cadence: '55 * * * *' #Every hour at 55 minutes past the hour
    Do not set to a low frequency like every minute
    If the cluster scanning job launches multiple simultaneous instances, it is more likely to get in a bad state.

  8. Click Create commit…

  9. Select Commit to master branch

  10. Under ‘Commit Message’, Type [skip ci] Adding Manfest Security Scanning

  11. Click Commit

    The time can be updated to retrigger the agent if there are problems getting it to run.

  1. Watch the previously opened view of the GitLab Agent log for deployment activity.

For Instructor-Led: the instructor may have this view displayed for everyone

  1. [Automation Wait Time: ~5 mins] Wait for the cluster to receive the new directive and perform a scan.

  2. To see scanning results, while in ‘classgroup/cluster-management’

  3. Click Infrastructure => Kubernetes clusters => spot2az-agent1 => Security (Tab)

  4. Under ‘Status’ Click [to expand the drop down] and then Click All statuses

  5. These findings are also visible in the standard security dashboards.

  6. Open ‘classgroup’

  7. On the left navigation, Click Security & Compliance => Vulnerability Report

  8. In the tab bar under ‘Vulnerability report’, Click Operational vulnerabilities

  9. Under ‘Status’ Click [to expand the drop down] and then Click All statuses

    Notice the list of vulnerabilities.

Accomplished Outcomes
  1. Configure Operational Container Scanning using the GitLab Agent for Kubernetes.
  2. Examine Operational Container Scanning findings.
Warning
To speed up the class results we set the cluster scanner to every minute. If this is a long lived cluster it would be prudent to update the starboard:cadence above to once a day or less.