The processes and tools of DevOps are effective in speeding up development cycles and improving reliability, as well as other technical, business, and organizational benefits. Those same qualities can likewise improve application security.
DevOps improves efficiency by:
- Establishing a unified organizational culture
- Enabling tighter feedback loops and faster review cycles
- Encouraging collaboration, and
- Implementing repeatable, automated, auditable configurations
GCP provides developers with tools to build sophisticated DevOps pipelines. GCP also helps make security a natural part of that process, creating an effective DevSecOps environment.
Planning
Integrating security into any DevOps pipeline requires preparation and planning. This can take months or even years to perfect. Nevertheless, even a small commitment to security can lead to significant improvements across the entire process.
Involving security teams in the DevOps process allows them to provide the expertise, frameworks, and tools for developer and operations teams to do their share. The key is to make security a natural part of the pipeline rather than introducing additional bottlenecks that might slow deployment (which is completely counter to DevOps.)
Protecting resource access is the foundation for information security and especially cloud security. This begins with authentication and authorization: verifying users via credentials and determining which resources they can access.
At the heart of access control is the Google Cloud Identity and Access Management (IAM) service. This allows you to manage user accounts and the resources on which they can act. IAM provides a granular, least-privilege approach to securing resources, primarily using specific roles for each cloud service.
In IAM, entities that access resources are called members. A member can be:
- Google Workspace or Cloud Identity, a centrally managed account attached to a domain and managed through Google’s Admin Console
- General Google Account, an unmanaged account created with Gmail, Chrome browser, or another Google Service
- Service Account, a special type of account that an application uses for gaining access to cloud resources
Resource Hierarchy
Resources refer to the services and data you use on GCP. A resource can be anything a cloud user might interact with, such as a container image, a build artifact, or a compute engine instance. GCP uses a hierarchy to organize resources -- the broadest group at the top, narrowing in scope as it moves down. Likewise, the policies you assign should also follow the same pattern. All resources inherit policies from their parents, so any policies set on parent folders should only allow minimal permissions since these will flow to child resources. This allows for greater job-specific access with adequate controls.
Permissions – Example
Although every situation is unique, here is one example of how you can set permissions:
Suppose your resource hierarchy has a development team that manages both intranet and external web applications. Using IAM groups and roles, you can create a generic set of permissions on a top-level folder for that team that includes the folders for each of the web app projects. Because resources inherit roles from parent folders, all child folders, projects, and resources will now have that generic set of access.
Next, you may want to give certain DevOps members on the intranet project special permissions to resources for which they are responsible. You can do that by setting a tag on these resources and a corresponding tag for the members of those teams. Like roles, tags are also inherited.
Finally, you can set conditional roles for an individual folder, project, or resource. Conditional roles are useful for setting more precise or granular permissions and for handling special situations.
Continuous integration/continuous delivery (CI/CD)
The CI/CD pipeline plays a major role in DevOps and is the primary vector for injecting security into the process. The CI/CD pipeline directs and automates the process, starting with committing code to deployment and operation in production.
Google Cloud Build provides build-and-release services to support continuous integration and delivery of applications. Using triggers, GCBuild enables automation of security at different phases. The process begins with a commit to a source repository (or by using a webhook with an external repository such as GitHub.) This triggers the pipeline processing, which will go through each step of the build and deployment stages.
To inject security into the pipeline, focus on three key strategies:
- Identify Test Points: in each stage, both automated and manual security testing should be performed
- Determine secrets, such as encryption keys or service credentials, that need protecting
- Encrypt all data in transit and at rest
Identifying where to perform security testing largely depends on the type of product and how it’s built. For example, a web application may require Static Application Security Testing (SAST), Dynamic Application Security Testing (DAST), Interactive Application Security Testing (IAST), and/or fuzzing. You might integrate each of these into different pipeline steps via shell scripts or external applications. Depending on the returned results, you would fail or approve the build and save necessary assets in the artifacts registry or a source repository.
Logging
A solid DevSecOps pipeline must provide feedback to each of the teams. Feedback, metrics, and observability require data, which you can log using the Google Cloud Logging service.
The Google Cloud Logging works across all Google Cloud services and integrates with the Cloud Monitoring, Error Reporting, and Cloud Trace services. You can use Cloud Logging to securely store, analyze, report on, and create alerts for logged events. The Logs Dashboard allows you to view charts and aggregated metrics. There is also the Logs Explorer, which allows you to stream or query logs with criteria you specify. Cloud Logging provides access to Cloud Audit Logs, which includes the Admin Activity, Data Access, System Event, and Policy Denied audit logs. These will be the most useful for ensuring the integrity of your DevOps activities.
About Ed Adams, CEO
Ed Adams is a software quality and security expert with over 20 years of experience in the field. He served as a member of the Security Innovation Board of Directors since 2002 and as CEO since 2003. Ed has held senior management positions at Rational Software, Lionbridge, Ipswitch, and MathSoft. He was also an engineer for the US Army and Foster-Miller earlier in his career.
Ed is a Ponemon Institute Research Fellow, Privacy by Design Ambassador by the Information & Privacy Commissioner of Canada, Forbes Technology Council Member, and recipient of multiple SC Magazine’s Reboot Leadership Awards. He sits on the board of Cyversity, a non-profit committed to advancing minorities in the field of cyber security, and is a BoSTEM Advisory Committee member.
