Google Cloud Run Security Best Practices

Google Cloud Run is a fully managed serverless container platform to run your code, functions, or container on Google’s infrastructure. The serverless approach offers significant benefits over traditional infrastructure-as-a -service (IaaS) models, such as automatic scaling (including scale to zero), pay-per-use billing, and simplified deployment. Instead of managing virtual machines, operating systems, and patching, Cloud Run allows developers to deploy code with speed and agility. Security is also built-in, with two layers of sandboxing for all workloads, integration with Google Cloud identity and access management (IAM), network security, data protection, and threat detection services.

Despite its managed nature, Cloud Run deployments are not immune to security threats. Key challenges and security risks include:

• Insecure container images: Deploying containers with known vulnerabilities can expose applications to compromise.
• Insecure secrets management: Storing sensitive data like API keys or database credentials in code or environment variables poses a significant risk.
• Supply chain attacks: Unsigned container images or unvetted third-party dependencies can introduce malicious code.
• Excessive permissions: Broad or misconfigured IAM roles can be abused for privilege escalation or unauthorised access to resources. These violate the principle of least privilege, increasing the blast radius of a potential breach.
• Insufficient logging and monitoring: Inadequate logging and monitoring make it difficult to detect, investigate, and respond to security incidents effectively.
• Network exposure: Misconfigured ingress and egress settings can expose services to unintended networks or allow malicious outbound connections.
• Denial of Service (DoS) attacks: Publicly accessible services can be targets for DoS attacks, leading to service unavailability and increased costs.

To mitigate these risks and secure your Cloud Run deployments, consider the following best practices and recommendations.

Identity and Access Management (IAM)

• Use dedicated service accounts with least privilege: Assign each Cloud Run service its own service account. Grant only the minimal IAM roles necessary. Avoid using default service accounts or broad roles like roles/editor.
• Restrict invoker roles: Control who can invoke your Cloud Run services. For public endpoints, this may include allUsers. For private services, grant roles/run.invoker role to specific identities such as users, service accounts, or trusted Cloud Run services.
• Limit service account key usage: Avoid creating user-managed service account keys. Prefer Google-managed credentials, workload identity federation, or service account impersonation for secure, short-lived access.
• Regularly audit IAM policies: Periodically review IAM policies at both the project and service level to remove unused or excessive permissions.
• Enforce custom organization policies: Use organization policy service to define guardrails e.g. restrict public access, enforce VPC egress, or limit allowed IAM roles for Cloud Run deployments.
• Define principal access boundaries: Prevent undesired access by defining the resources that principals can access.

Container and Supply Chain Security

• Use minimal base images: Start with lean, trusted base images - such as distroless images or minimal OS images - to shrink your attack surface.
• Scan images for vulnerabilities: Integrate vulnerability scanning into your CI/CD pipeline. Use Artifact Analysis (via Artifact Registry) or third-party tools to identify and remediate known vulnerabilities before deployment.
• Run containers as a non-root user: In your Dockerfile, set USER to a non-root UID. This limits damage if an attacker escapes from the container.
• Use immutable image tags: Pin deployments to specific image digests or version tags instead of latest. This guarantees consistency and prevents accidental upgrades.
• Digitally sign and verify images: Enforce image provenance with Binary Authorization. Only allow containers that are signed and attested by your trusted build process to be deployed to your environment.
• Remove unused packages: Exclude shells, debugging tools, and compilers unless they're strictly needed in production images.
• Enable automatic base image updates: When you use Cloud Run's source deploy workflow (or a multi-stage Dockerfile), Google Cloud's buildpacks apply the latest security patches to the base layer, keeping the image up-to-date without manual intervention.
• Gather software supply chain insights: Collect and review metadata at each pipeline stage: SBOMs to track dependencies, build provenance, CI/CD audit logs, and SLSA attestation.

Secure Development and Deployment

• Secure your CI/CD pipeline: Lock down all components of your continuous integration and continuous deployment (CI/CD) system - secure source code repositories, isolate build runners, and protect artifact storage.
• Manage dependencies proactively: Regularly scan and update application dependencies for known vulnerabilities to minimise exposure to attacks.
• Validate all user input: Implement strong input validation and output encoding to protect against common web vulnerabilities like Cross-Site Scripting (XSS), SQL injection, and others.
• Configure concurrency and timeouts safely: Set appropriate concurrency limits and request timeouts in your Cloud Run service settings to mitigate abuse and avoid excessive resource usage.
• Use a secrets management solution: Store sensitive data like API keys, database credentials, and certificates, in Secret Manager. Avoid embedding secrets in code, configuration files or environment variables.
• Grant fine-grained access to secrets: Use IAM to control which service accounts can access specific secrets. Apply the principle of least privilege. Automate secret rotation where feasible.
• Inject secrets at runtime only: Mount secrets as environment variables or volumes in your Cloud Run service directly from Secret Manager. Ensure secrets are not logged, committed to source, or exposed during builds.
• Use customer-managed encryption keys: By default, Cloud Run encrypts data at rest using Google-managed encryption keys. Use Cloud KMS for increased control over key protection level, location, rotation schedule, usage and access permissions, and cryptographic boundaries.
• Test security continuously: Perform regular security assessments, including static analysis, dependency audits, penetration testing, and manual code reviews, for your Cloud Run applications.

Network Security

• Control ingress traffic: Configure the ingress settings to limit who can reach your Cloud Run endpoints. Prefer restrictive options such as "Internal" or "Internal and Cloud Load Balancing" over "All" to reduce overall exposure.
• Use VPC connectors for private access: When accessing private Google Cloud resources (like Cloud SQL or Memorystore), use Serverless VPC Access connectors. Secure the connector itself with appropriate firewall rules.
• Use Direct VPC egress for private access (new): Optionally, use the newer Direct VPC egress option to send traffic to a VPC network with no Serverless VPC Access connector required.
• Restrict egress traffic: Apply egress restrictions via firewall rules, DNS policies, or VPC Service Controls, to prevent Cloud Run services from sending data to untrusted external destinations.
• Protect public services with Cloud Armor: Deploy Cloud Run behind an external HTTP(S) Load Balancer integrated with Cloud Armor to protect against DDoS attacks and enforce web application firewall (WAF) policies.
• Enforce HTTPS everywhere: By default, Cloud Run manages TLS for the *.run.app domains. For custom domains, ensure HTTPS is enforced.
• Disable default endpoint URL: Disable the default *.run.app URL, and only allow traffic from the service’s other ingress paths like Cloud Load Balancing and any configured domain mappings.
• Enable Identity-Aware Proxy (IAP): Optionally, enable IAP with a single click for easier authentication and context-aware access.

Logging and Monitoring

• Enable and centralise logging: Enable Admin Activity and Data Access logs for Cloud Run to capture administrative actions and access events. Ensure that your application logs provide sufficient detail for security analysis.
• Configure log-based alerts: Set up alerts in Cloud Monitoring based on specific log patterns or metrics that could indicate suspicious activity or security events (e.g., excessive authentication failures, unexpected error rates).
• Use Cloud Audit Logs: Regularly review audit logs to detect unauthorised changes or suspicious access to your Cloud Run services.
• Enable Cloud Run Threat Detection (CRTD): Activate CRTD (available with Security Command Center Premium or Enterprise) to detect runtime threats like remote shell access, exploit attempts, or malicious payload execution. CRTD correlates findings with Artifact Analysis, allowing you to pinpoint the base artifact that introduced the vulnerability.
• Monitor service and security metrics: Track key metrics like request latency, error rates, CPU utilisation, and instance counts in Cloud Monitoring. Anomalies can sometimes indicate underlying security issues.

By implementing these technical best practices, you can significantly enhance the security posture of your Google Cloud Run services, protecting your applications and data from a wide range of threats.