DevSecOps has become the default standard for organizations striving to achieve an efficient but secure software deployment process. Not only does it ensure an efficient environment, it also unifies the process of integrating security, starting from the ground up—from the infrastructure to the application stack.
In earlier articles, we touched upon the basics of DevSecOps and how to secure cloud-native applications with DevSecOps. With cloud adoption on the rise, the focus is now shifting toward the integration of DevSecOps practices directly into the cloud environment.
Cloud service providers advocate a shared responsibility model for security, and adopting a DevSecOps approach helps organizations incorporate the right security controls at each stage of application development. We have already discussed how this works for different platforms, including security for Google Cloud Platform (GCP), how to use GCP securely, and a specific article on how to use DevSecOps to strengthen security on Google Cloud.
In this article, we will look into some additional features and services that can enhance DevSecOps and cloud security for GCP. We will cover organizational policies and cloud operations suites, VPC service controls, and data encryption via customer-supplied encryption keys, as well as binary authorization for containers, and more.
Organizational Structure & Policies
Identity and access management in Google Cloud Platform (GCP) enables control plane security of your cloud environment and helps to enforce the principle of least privilege. The security scaffolding comes from the hierarchical structure of organizations, folders, projects, and resources in GCP. The rule of thumb is to segregate different environments into different projects or folders and define permissions at the top level for more centralized control. (We’ve previously written about organizing GCP resources for better security.)
To enhance the security of cloud environments, Google Cloud also provides an organizational policy service, giving you programmatic control of your resources and allowing you to implement and manage restrictions centrally. While IAM controls which users can have access to resources, organizational policies define what resource configurations are allowed for those users, how they can be used, and the restrictions around them. It also helps build compliance guardrails for development teams; for example, if your application has data residency requirements for a specific location, you can implement policies to allow for deployments only on compliant cloud regions.
You can implement additional constraints on the usage of external IP addresses, service accounts, serial ports, etc. through organizational policies. A policy applied at the organization’s root node is inherited to all descendant resources, i.e., folders, projects, and cloud resources. If any of the cloud services do not comply with the applied organizational policy, it will be flagged as a violation and the constraint will be executed.
Note: Policies are not retroactive, so you should plan them at the initial stage of your cloud design for effective implementation.
Google Cloud’s Operations Suite
Google Cloud’s operations suite, formerly known as Stackdriver, provides a unified platform for logging and monitoring applications deployed on GCP. It is custom-built to align with your SRE strategy and allows customers to define and monitor service-level objectives (SLOs) for deployed workloads. These SLOs are, in turn, based on the performance metrics quantified by service-level indicators (SLIs).
Cloud logging enables centralized logging and analysis of logs from Google Cloud resources as well as components that are part of your hybrid and multi-cloud architecture. To correlate the logs from multiple sources and derive deeper insights, you can use the Log Analytics service (in preview). This service is backed by Google’s flagship data warehousing solution called Big Query.
To ensure comprehensive security and drive accountability, GCP offers an always-on audit trail for admin activity through Cloud Audit Logs. This audit trail cannot be disabled and provides you with visibility into changes made by administrators in your cloud environment. Google Cloud also has an Access Transparency service, which can log the activities performed by Google support engineers in real time if you engage their services due to an incident.
Enhanced Network Protection
We’ve written previously about best security practices for Google Cloud’s VPC (Virtual Private Cloud) and firewall rules. You can use the latter to implement fine-grained control over ingress and egress traffic, permitting only the required traffic to pass through the network.
In addition to firewall rules, you can also use VPC Service Controls to augment your GCP network security, define service perimeters at the organizational level to mitigate the risk of data exfiltration, or authorize clients in a perimeter to access specific resources only. They also enable private communication between cloud resources like Cloud Storage, Cloud Bigtable, BigQuery, etc., as well as on-premises resources in hybrid architectures when integrated with Private Google Access.
GCP customers can additionally implement a Shared VPC for secure communication between resources in different projects using internal IPs. GCP Shared VPC lets you implement a hub-and-spoke architecture with shared resources deployed in a centralized host project. It also helps implement the principle of least privilege by providing network administrators permissions only on the network and not on the connected projects. If you need fine-grained access control over subnets, GCP supports IAM policy assignment at the subnet level (currently in beta) as well.
All data stored in GCP is encrypted at rest by default through Google-managed encryption. However, Cloud Key Management Service (KMS) in GCP provides customers the flexibility of having their own encryption keys as well. The service allows you to generate, store, and manage the lifecycle of all keys used by your applications.
If you don’t want to store the keys in KMS, but still want to use your own key for data encryption, there’s an option to do that as well using Customer-Supplied Encryption Keys (CSEK). This is currently supported for Cloud Storage and Compute Engine. Customers can provide a raw CSEK in API calls, which is used for encrypting the data. This key is never stored unencrypted on disk, and is not stored permanently by GCP in any of its servers; this way, customers remain the custodian of the key and exercise full control over how they want to use it.
Infrastructure as Code
Automating the deployment of infrastructure along with application code using Infrastructure as Code (IaC) is an essential component of DevSecOps and shifting security left in your SDLC. It helps ensure consistency, repeatability, and easier lifecycle management of your infrastructure. You need to include the right security hardening configurations in this process so that your environment is protected against any kind of attacks from day one.
Cloud Deployment Manager is GCP’s native service for implementing IaC. Along with resource deployment, you can also implement Cloud Deployment Manager to set IAM permissions so that the principle of least privilege is baked into the process.
Note: You should always have separate service accounts that are used exclusively for infrastructure deployment; you should also consider segregating IaC pipelines for different business units.
There are other existing tools you can leverage for automation purposes, including Terraform, Puppet, and Ansible. GCP even provides security blueprints and associated Terraform modules you can use to build secure foundation services and infrastructure for your workloads.
Microservices-based architectures using containers have become commonplace in the cloud, and your overall strategy should include measures that provide security for containers. On this front, GCP offers a container analysis service to scan and detect software vulnerabilities in container images hosted in the GCP Container Registry or Artifact Registry. The scanning can either be on-demand or automated; any new images uploaded to the Container/Artifact Registry are automatically scanned for vulnerabilities. Continuous analysis of the uploaded images is then performed against updated vulnerability data from various sources to ensure comprehensive security. You can also initiate on-demand scans of images as needed.
To implement additional security, you can enable Binary Authorization for containers to make sure only trusted container images are deployed on container hosting services like GKE and Cloud Run. The images should be signed by a trusted authority for them to be deployed. You can incorporate this in DevSecOps practices by configuring your CI/CD pipelines to enforce the validation of image signatures. Any images that do not meet your security standards will be rejected, and only validated images will be deployed.
GKE is the managed Kubernetes service from Google Cloud, where the control plane operations of the cluster are handled by GCP. Users can focus on their containerized workloads, only needing to manage the nodes where they are deployed. GKE Autopilot takes this one step further by providing a hands-free approach with operational aspects like nodes and node pools also being managed by the service.
GKE Autopilot comes with pre-built security controls that help you establish a secure production-ready environment for your containers without operational overhead. It uses workload identity to securely authenticate applications hosted in GKE to use Google Cloud APIs, while GKE Autopilot clusters use Shielded GKE nodes to prevent attackers from exploiting pod vulnerabilities and gaining access to cluster nodes. It also has Secure Boot enabled, which ensures that the system does not load any unsigned kernel modules from third-party providers. Additional features like CMEK, application-layer Secrets encryption, and Google Groups-based RBAC are also supported in GKE Autopilot for enhanced security.
Cloud adoption has brought a paradigm shift in how workloads are built, deployed, and managed traditionally. Adopting DevSecOps practices is a top priority for cloud-native organizations to build an efficient software delivery process aligned with GCP security best practices. The native services from GCP that we discussed above can help you in this process. However, for full protection of web applications and APIs hosted in the cloud, additional measures are necessary. This includes a specialized cloud native web security solution such as Reblaze, that integrates into your DevSecOps processes and provides a next-generation WAF, DDoS protection, advanced bot management, API security, and other vital components of a modern web security posture. For more information, contact us.