Workload Configuration
In order to instrument google cloud run workloads the tracer will need to be utilized.
Configuring a workload to be instrumented with the tracer requires embedding the tracer as part of the container image directly at build time.
An additional requirement for cloud run workloads is that execution environment gen2 is selected in order to be able to utilize ptrace efficiently.
resource "google_cloud_run_v2_service" "workload" {
template {
execution_environment = "EXECUTION_ENVIRONMENT_GEN2"
}
}
Add the Upwind Tracer to your Dockerfile
This step involves (a) adding a build stage, (b) copying the Upwind Sensor binary, and (c) setting up the entrypoint
Below is a simple example of a Dockerfile with these additions:
# syntax=docker/dockerfile:1
# (a) Add the Upwind Tracer image as a build stage.
FROM public.ecr.aws/upwindsecurity/images/tracer:0.3.1 AS upwind-tracer
# (b) Copy the tracer binary into your workload image
FROM workload-image
# (c) Copy the Upwind Tracer binary from the build stage.
COPY /var/lib/upwind /var/lib/upwind
# (d) Set the default entrypoint to the Upwind Tracer.
ENTRYPOINT ["/var/lib/upwind/upwind-tracer", "/path/to/your/app"]
Build and Push Image
After defining and creating your image, you need to push it to a container registry
Configure tracer to cluster manager communication
The tracer pushes telemetry to the upwind cluster manager via gRPC connection. In order to configure the tracer a pair of environment variables need to be set on the workload service / job definition
env {
name = "UPWIND_TRACER_API_HOST"
value = "{CLUSTER_MANAGER_URI}"
}
env {
name = "UPWIND_TRACER_EXTENDED_SYSCALLS"
value = "true"
}
The value for the UPWIND_TRACER_API_HOST
variable can fetched by consuming the output variable upwind_cluster_manager_uri
from the terraform integration, see the output variables here
In order for the tracer to identify layer 7 traffic http requests you have to turn on extended syscalls UPWIND_TRACER_EXTENDED_SYSCALLS
.