The Service Graph Connector for GCP (SGC-GCP) is part of the Service Graph integration projects. The connector is built to simplify the onboarding setup and ease the integration across multiple GCP projects in an organization. This application uses one ServiceNow service account to pull in data from all of the folders and projects in an GCP Organization. This article describes the concepts and setup of the Service Graph Connector for GCP.
Objectives of SG-GCP
- Simplify on-boarding experience
- Minimal credentials requirement
- No MID server required
- Coverage for multiple GCP folders and projects across the organization
Summary:
- GCP Organization Structure
- Service Perimeter (VPC Perimeter)
- Cloud Asset Inventory (CAI)
- IAM Security
- Service Account & P12 certificate
- Setup Instructions
- Discovered CIs
1. GCP Organization Structure
In Google Cloud Platform (GCP), an organization is the top-level resource that represents a company, and it can contain multiple folders, projects, and billing accounts. Folders are used to group projects together based on organizational hierarchy, while projects are used to organize and manage resources such as virtual machines, storage buckets, and databases.
Projects exist within folders, and each project must belong to a folder. A project can also be moved between folders, but it can only belong to one folder at a time. Within a folder, projects can inherit policies, permissions, and settings from the parent folder, or they can have their own unique configurations.
The relationship between folders and projects allows for centralized management and governance of resources across an organization. By organizing projects within folders, administrators can apply policies and controls at a granular level, while still maintaining a consistent framework across the organization. Additionally, the folder hierarchy allows for the delegation of permissions and responsibilities to specific teams or individuals.
We have the following folder and project structures in a GCP organization for our various concept presentations.
2. Service Perimeter (VPC Perimeter)
A GCP Service Perimeter is a security boundary that is used to protect sensitive resources within an organization. It is a virtual boundary that encompasses a set of resources, such as GCP projects, VPC networks, and Cloud Storage buckets, and defines the access controls and policies that apply to those resources.
Service Perimeters are used to enforce access controls on resources that are exposed to the internet or that are accessible from other GCP projects. They allow administrators to define a set of authorized services, IP addresses, and users that can access resources within the perimeter, while blocking all other traffic.
Service Perimeters are created and managed using the Google Cloud Console or the Cloud SDK, and they can be configured to allow or deny traffic based on a wide range of factors, such as user identity, device status, and geographic location. They also support the use of firewall rules and custom access levels, which enable administrators to fine-tune the access controls for specific resources or groups of users.
Overall, Service Perimeters provide a powerful tool for securing sensitive resources within an organization, and they help ensure that only authorized users and services have access to those resources. Some organizations have service perimeter defined and SGC-GCP fully supports this setup.
For our discussion, a GCP organization with service perimeter enabled has the following folder and project structures.
3. Cloud Asset Inventory
The GCP Cloud Asset Inventory is a service that provides a unified view of all the assets and resources in a GCP project or organization. It allows administrators to track and manage their cloud assets and resources across different GCP services, such as Compute Engine, Cloud Storage.
Cloud Asset Inventory retrieves metadata about resources and services, such as configuration settings, labels, and policies, and it stores this information in a centralized repository. The metadata is updated in near-real-time, so it provides administrators with an up-to-date view of their cloud environment.
The Cloud Asset Inventory can be used to search and filter assets based on different criteria, such as resource type, name, and label, allowing administrators to quickly locate and manage specific resources. Additionally, it supports the use of asset inventory feeds, which enable administrators to export asset metadata to other services, such as Pub/Sub or Cloud Storage.
Overall, the Cloud Asset Inventory provides a comprehensive and scalable way to manage and track cloud assets and resources in GCP, enabling administrators to gain better visibility into their cloud environment and improve their security and compliance posture.
SGC-GCP requires that CAI be enabled in all projects in which you are interested in obtaining the CI details.
4. IAM Security
In GCP, IAM (Identity and Access Management) permissions are used to control access to resources within a project. IAM permissions are assigned to roles, which are collections of permissions that define what actions a user or service account can perform on a particular resource.
SGC-GCP requires limited read-only permissions to access specific APIs. Depending on the access level you require, you may need to create one or more roles. If you want to allow a ServiceNow user to access all projects, you need one service account and one IAM role. However, if you need to grant limited permissions at the folder or project level, you'll need to create multiple service accounts and IAM roles.
Here is the list of IAM permissions required to access various APIs
- resourcemanager.organizations.get
- resourcemanager.folders.list
- resourcemanager.folders.get
- resourcemanager.projects.get
- cloudasset.assets.listOSInventories
- cloudasset.assets.exportOSInventories
- cloudasset.assets.listResource
- cloudasset.assets.exportResource
- cloudasset.assets.searchAllResources
- compute.disks.get
- compute.images.list
- compute.machineImages.get
- compute.machineImages.list
- compute.machineTypes.get
- compute.zones.get
4.1 Service Account with all projects access:
If you are creating one service account for the entire organization, you need to create a service account in any project and create one role (SnowOrgRole) at the organization level. Then, you can bind the role with the service account. This will give access to all folders and projects.
Here, the ServiceNow service account is created in Project 2, and the SnowOrgRole is created at the organization level and bound together. This gives the service account access to all projects in the organization.
4.2 Service Account with limited project access or Service Perimeter:
If you have service perimeter enabled, you need to create one user per perimeter and two roles - one at the organization level and another at the project level. This is because the Organizations and Folder details APIs are accessible only at the organization level.
In this scenario, we need to create two roles - SnowOrgRole and SnowProjRole.
The below list of IAM permissions are applicable only at organization level with the role 'SnowOrgRole'.
- resourcemanager.organizations.get
- resourcemanager.folders.list
- resourcemanager.folders.get
Below IAM permissions should be created in each project level with a role name 'SnowProjRole'
- resourcemanager.projects.get
- cloudasset.assets.listOSInventories
- cloudasset.assets.exportOSInventories
- cloudasset.assets.listResource
- cloudasset.assets.exportResource
- cloudasset.assets.searchAllResources
- compute.disks.get
- compute.images.list
- compute.machineImages.get
- compute.machineImages.list
- compute.machineTypes.get
- compute.zones.get
Suggested role names are SnowOrgRole and SnowProjRole, but you can define role names according to your company standards.
In this scenario, a service account is created in each perimeter, and the account is bound to SnowProjRoles within the projects of the perimeter, and to the SnowOrgRole at the organization level. By binding the service account and project roles, you can restrict access to only the specific projects you want to import CI details for.
5. Service Account & P12 certificate
A GCP Service Account is created to authenticate and authorize access to GCP APIs. The Service Account is bound with roles that were created in a previous section. To obtain an Access Session Token from the GCP IAM API and access the GCP APIs, you need to create a P12 file by following the steps described in the Setup Instructions KB article.
Once the P12 file is created, it can be registered in the ServiceNow instance. SGC-GCP will then use this certificate to obtain an Access Session Token from the GCP IAM API and access the GCP APIs, as shown in the sequence diagram below.
6. Setup Instructions
Setup instructions are described in the KB Article (KB1220598).
7. Discovered CIs
Kubernetes specific CIs:
