Runtime Security Insights

1. Introduction

In this lab you will deploy an application to Cloud Run and GKE cluster and view security insights for the deployment in the Software Delivery Shield Security

What you'll learn

• Artifact Registry Security Insights
• Cloud Run Security Insights
• GKE Security Posture

2. Setup and Requirements

Cloud Project setup

1. Sign-in to the Google Cloud Console and create a new project or reuse an existing one. If you don't already have a Gmail or Google Workspace account, you must create one.

• The Project name is the display name for this project's participants. It is a character string not used by Google APIs. You can update it at any time.
• The Project ID is unique across all Google Cloud projects and is immutable (cannot be changed after it has been set). The Cloud Console auto-generates a unique string; usually you don't care what it is. In most codelabs, you'll need to reference the Project ID (it is typically identified as PROJECT_ID). If you don't like the generated ID, you may generate another random one. Alternatively, you can try your own and see if it's available. It cannot be changed after this step and will remain for the duration of the project.
• For your information, there is a third value, a Project Number which some APIs use. Learn more about all three of these values in the documentation.

Caution: A project ID is globally unique and cannot be used by anyone else after you've selected it. You are the only user of that ID. Even if a project is deleted, the ID can never be used again

Note: If you're using a Gmail account, you can leave the default location set to No organization. If you're using a Google Workspace account, then choose a location that makes sense for your organization.

2. Next, you'll need to enable billing in the Cloud Console to use Cloud resources/APIs. Running through this codelab shouldn't cost much, if anything at all. To shut down resources so you don't incur billing beyond this tutorial, you can delete the resources you created or delete the whole project. New users of Google Cloud are eligible for the $300 USD Free Trial program.

Environment Setup

Activate Cloud Shell by clicking on the icon to the right of the search bar.

From Cloud Shell, enable the APIs required for this lab:

gcloud services enable run.googleapis.com \
  cloudbuild.googleapis.com \
  artifactregistry.googleapis.com \
  container.googleapis.com \
  containersecurity.googleapis.com

If prompted to authorize, click "Authorize" to continue.

This should produce a successful message similar to this one:

Operation "operations/acf.p2-327036483151-73d90d00-47ee-447a-b600-a6badf0eceae" finished successfully.

Run the command to create the GKE cluster asynchronously. It will be used in later in the lab:

gcloud beta container clusters create gke-cluster \
    --zone us-central1-a \
    --async

3. Prepare Application

First, you will prepare a simple express-based Node.js application that responds to HTTP requests.

In Cloud Shell create a new directory named starter-nodejs, then change into that directory:

mkdir starter-nodejs
cd starter-nodejs

Create a package.json file, by running commands below:

cat > ./package.json << EOF
{
  "name": "cloudrun-starter-app",
  "version": "1.0.0",
  "description": "Node.js Starter Application",
  "main": "index.js",
  "scripts": {
    "start": "node index.js"
  },
  "author": "",
  "license": "Apache-2.0",
  "dependencies": {
    "express": "^4.18.2"
  }
}
EOF

The file above contains a start script command and a dependency on the Express web application framework.

Next, in the same directory, create a index.js file by running commands below:

cat > ./index.js << EOF
const express = require('express');
const app = express();

app.get('/', (req, res) => {
  console.log('Received a request.');
  res.send("Hello Cloud Run!");
});

const port = process.env.PORT || 8080;

app.listen(port, () => {
  console.log('Listening on port', port);
});
EOF

This code creates a basic web server that listens on the port defined by the PORT environment variable. Your app is now finished and ready to be containerized and deployed.

4. Deploy Cloud Run Application

Run the command below to deploy your application:

gcloud run deploy starter-app \
  --source . \
  --region us-central1 \
  --allow-unauthenticated \
  --max-instances=3

Confirm Artifact Registry repository creation:

Deploying from source requires an Artifact Registry Docker repository to store built containers. A repository named [cloud-run-source-deploy] in region [us-central1] will be created.

Do you want to continue (Y/n)? y

5. Artifact Registry and Cloud Build Security Insights

It will take a few minutes for the build to complete.

Open Cloud Build and review build artifacts for the latest build.

The Cloud Build UI in the Google Cloud console contains the Software Delivery Shield Security insights panel that displays security information related to the build such as SLSA level, any vulnerabilities in the dependencies, and build provenance.

Review Security Insights for created container image. Follow the link for scanned artifacts to view the vulnerabilities details for this image in Artifact Registry.

Return to the Cloud Shell console and verify that Cloud Run application deployment is complete.

Done.
Service [starter-app] revision [starter-app-00001-maw] has been deployed and is serving 100 percent of traffic.
Service URL: https://starter-app-nin5jpgefq-uc.a.run.app

6. Cloud Run Security Insights

Cloud Run contains a security panel (Preview) that displays software supply chain security insights such as the SLSA build level compliance info, build provenance, and vulnerabilities found in running services.

Open Cloud Run and review Security Insights under REVISIONS / SECURITY tab.

This panel displays the following information:

• Identity and encryption: The email address of the default Compute Engine service account and the encryption key used for the deployment.
• SLSA Level: This build is at SLSA Level 3, which identifies the maturity level of software build process in accordance with the SLSA specification
• Vulnerabilities: Any vulnerabilities found in application dependencies.
• Build details: Details of the build such as the builder and the link to view logs.
• Build provenance: Provenance for the build, which is a collection of verifiable metadata about a build. It includes details such as the digests of the built images, the input source locations, the build toolchain, build steps, and the build duration.

7. GKE Security Posture

GKE can assess your container security posture and give active guidance around cluster settings, workload configuration, and vulnerabilities. It includes the security posture dashboard (Preview), that scans your GKE clusters and workloads to provide you with opinionated, actionable recommendations to improve your security posture.

In the next steps, you will deploy the application to the GKE cluster and review security insights in the GKE security posture dashboard.

Verify that cluster is ready by running following command:

gcloud beta container clusters list

Sample output:

NAME: gke-cluster
LOCATION: us-central1-a
MASTER_VERSION: 1.24.9-gke.3200
MASTER_IP: 34.29.226.228
MACHINE_TYPE: e2-medium
NODE_VERSION: 1.24.9-gke.3200
NUM_NODES: 3
STATUS: RUNNING

Get credentials and configuration for the GKE cluster:

gcloud container clusters get-credentials gke-cluster  \
    --region=us-central1-a

Run the command to deploy application using image that was built in previous step:

export PROJECT_ID=$(gcloud config get-value project)

kubectl run starter-app \
  --image us-central1-docker.pkg.dev/${PROJECT_ID}/cloud-run-source-deploy/starter-app:latest \
  --port 8080

The GKE workloads should ideally have a hardened configuration that limits their attack surface. Checking workloads across clusters for configuration issues can be difficult to do manually at scale. You can use the security posture dashboard to automatically scan the configuration of all your running workloads across multiple clusters and return actionable, scored results and opinionated recommendations to improve your security posture.

Enable workload configuration scanning:

gcloud beta container clusters update gke-cluster \
    --region=us-central1-a \
    --enable-workload-config-audit

In addition to scanning workload configuration, you can also enable workload vulnerability scanning and review results in the security posture dashboard which is a set of features that provide opinionated information and recommendations to improve the security of your GKE clusters and workloads.

GKE automatically scans the container images in every eligible Pod running in your GKE cluster for known vulnerabilities, using vulnerability data from public CVE databases such as NIST.

If a vulnerability is found in your container images, GKE assigns a severity rating and displays the results in the security posture dashboard in the Google Cloud console. GKE also adds entries to Cloud Logging for auditing and traceability.

Enable workload vulnerability scanning:

gcloud beta container clusters update gke-cluster \
    --region=us-central1-a \
    --enable-workload-vulnerability-scanning \
    --async

Open the GKE Security Posture page.

Wait a few minutes for the workload audit to complete and then review the results.

Review Configuration concerns and affected workloads.

Why use the security posture dashboard

The security posture dashboard is a foundational security measure that you can enable for any eligible GKE cluster. Google Cloud recommends using the security posture dashboard in all your clusters for the following reasons:

• Minimal disruptions: Features do not interfere with or disrupt running workloads.
• Actionable recommendations: When available, the security posture dashboard provides action items to fix discovered concerns. These actions include commands that you can run, examples of configuration changes to make, and advice about what to do to mitigate vulnerabilities.
• Visualization: The security posture dashboard provides a high-level visualization of concerns affecting clusters across your project, and includes charts and graphs to show the progress you've made and the potential impact of each concern.
• Opinionated results: GKE assigns a severity rating to discovered concerns based on the expertise of Google's security teams and industry standards.
• Auditable event logs: GKE adds all discovered concerns to Logging for better reportability and observability.

8. Congratulations!

Congratulations! You have finished the codelab.

What we've covered:

• Security Insights information for build artifacts and application running on Cloud Run and GKE

Clean up

To avoid incurring charges to your Google Cloud account for the resources used in this tutorial, either delete the project that contains the resources, or keep the project and delete the individual resources.

Deleting the project

The easiest way to eliminate billing is to delete the project that you created for the tutorial.

—

Last update: 3/21/23