Discovering Google Cloud Platform
Node changes in Technology Knowledge Update TKU 2019-Dec-1
TKU December 2019 enhances the model for Cloud Regions and Cloud Services to be segregated by account. If you discover more than one AWS Account, more than one Azure Subscription or more than one GCP Project, all the data from Cloud Region through to individual nodes within services will be clearly separated, where before it was intermingled.
As a result, the keys of all CloudRegion and CloudService nodes, and many contained nodes will change, even if you only discover a single account. If you synchronize to a CMDB, the identities of the corresponding CIs will also change.
The existing nodes are not deleted automatically with the application of the TKU. To remove the old nodes from the BMC Discovery model, you can delete the patterns that were deactivated by the new patterns in the TKU. However, the old CIs in the CMDB will not be deleted automatically. The simplest way to remove them is to perform a resynchronization.
Discovering Google Cloud Platform
You access and configure all of your services, using the Cloud Console. This section describes the settings and procedures required to discover services running in GCP.
Services and regulatory domains discovered
BMC Discovery enables you to discover your cloud services running in GCP. The following set of GCP services can be discovered with the latest product content update:
Create a credential
To perform discovery on GCP, you should provide an access key (credential) with the help of which BMC Discovery can access the GCP cloud. You can create the access key using the GCP Identity and Access Management (IAM) console. Then, add the cloud discovery credential using the access key created in the IAM console, to BMC Discovery.
To create Access Key in the IAM console:
- Create a new service account user for discovery user with the following role:
Project → Viewer (Read access to all resources)
- Choose to furnish a new private key in json format. The access keys are used to make secure queries to the GCP APIs.
You can download the Access Private Key as a json file and then import it when you create a cloud credential in BMC Discovery.
If you lose the secret access key, you cannot retrieve it from the IAM console. In such a case, you should create a new access key and use this key in the BMC Discovery cloud credential. You should keep a note of the secret access key until you have successfully tested the cloud credential.
- (Optional) If you want to use one service account to scan multiple Google Projects, then add this service account to needed Google Projects with a role (Project → Viewer) in cloud resource manager:
Create a cloud credential in BMC Discovery
Create the cloud credential in the same way as any other credential. The cloud credential uses the Access keys/IDs/passwords as the equivalent of a username and password combination.
- From the BMC Discovery Device Credentials page, click Add and select Cloud Provider from the drop-down list.
The Add Credential page is displayed.
- Click the plus icon next to Credential Types to see the available Cloud Providers. Select Google Cloud Platform from the drop-down list.
- Add the usual credential information:
- Add the Service Account Key.
- Optionally, specify a proxy to be used for the access. To use a proxy, specify the following:
- Username (only for authenticating proxies)
- Password (only for authenticating proxies)
- Click Apply to save the credential.
Test the credential
Once you have created the credential, you should test it to ensure that it works:
From the credentials page, click Devices.
- Filter the list to show cloud credentials.
- Click Actions for the GCP cloud credential you added, and then click Test.
- The default region is US East 1 (S. Carolina).
- Click Test.
The screen below shows a successful test.
If the credential test was unsuccessful, click on the "Failure" status to see the details. Ensure that you copied the secret access key correctly. Also, you should ensure that the appliance time is no further than five minutes of the time GCP is using. See Time setting for more information.
The BMC Discovery appliance must be able to access GCP using the HTTPS (port 443).
Time synchronization is essential. You need to ensure that your appliance time is synchronized using NTP. If you do not use NTP, ensure that the time is no further than five minutes from the time GCP is using. GCP uses timestamped authentication and any discrepancy will result in authentication failures.
Run a cloud scan
To perform cloud discovery, from the Discovery Status page, use the Add New run control. After that, perform the following steps:
- Click Add New run.
The Add a Cloud Run dialog is displayed.
- Enter a Label for the cloud discovery run.
- To add a scheduled cloud run, select Scheduled and fill in the scheduling information as with normal scheduled discovery runs.
- Select Cloud.
- Select Google Cloud Platform from the providers drop-down list.
- Select the appropriate cloud credential. If none are available, add a new one.
- Select the region to scan, for example, GCP, US East 1 (S. Carolina). You can also select all regions by clicking the All.
- Click OK.
Once you have scanned, you can check the results.
Scan the hosts running the VMs in the cloud
Perform a normal scan on the hosts running the VMs discovered in the cloud scan. Use the Unscanned Cloud Hosts report on the Cloud Overview dashboard to find these.
Scanning the hosts assumes that the appliance or proxy has network access to hosts running in the cloud, for example, using a VPN.
Public IP addresses do not respond to ICMP pings. You must disable "Ping before scanning", otherwise all scans are dropped reporting no response.
You can discover all supported databases in GCP. At the time of release of BMC Discovery 11.3, the following are supported:
The following information is required to discover databases in GCP:
- Endpoint – you can identify the database endpoint using the RDS Dashboard in the GCP Console.
- Security groups
- If the endpoint is publicly accessible, you still should set up a security group with a rule to allow access from the IP address from which BMC Discovery connects.
If the database is not publicly accessible, discovery should be running in GCP. You should set up security to allow access from the Virtual Private Cloud (VPC) that BMC Discovery is running on, and be a part of a security group with a rule to allow access from the IP address from which BMC Discovery connects.
In GCP, all security groups prevent access by default, you should enable access ports in a security group before any access is allowed.
To summarize, you should configure security groups which enable the BMC Discovery appliance to access the database. This is entirely dependent on the way you have configured your GCP cloud services.
- Incoming connections – you should permit incoming connections with a rule for an IP address or set of IP addresses. For example, to permit access to a MySQL database, from a single IP address, add a rule with the following parameters:
- Type - MySQL
- Protocol - TCP
- Port Range - 3306
- Source - 22.214.171.124/32
Then, the database can be discovered as any of your other MySQL databases.
BMC Discovery database credential
To discover a Database an appropriate Database credentials must be created.
Information about Database credentials is available here in the Database credentials paragraph.
GCP discovery patterns
The GCP discovery patterns are available on the Manage > Knowledge page. They are located in the Pattern modules list, under Cloud > Google Cloud Platform.
GCP labels discovery
GCP labels are modeled as tags attributes, more information is available here.
Time out issue
Time out error while scanning on Virtual Machine
'time out' error could appear during scan of all Google regions when IPv6 is enabled on VM machine or from an AWS Outposts, but IPv6 addresses are not working in your network.
At first, check if IPv6 is enabled. For that, execute a command:
lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
inet 127.0.0.1 netmask 255.0.0.0
inet6 ::1 prefixlen 128 scopeid 0x10<host>
Then, check if IPv6 is working. Execute the following commands:
[root@centos ~]# ping6 accounts.google.com
PING accounts.google.com(muc11s02-in-x0d.1e100.net (2a00:1450:4016:801::200d)) 56 data bytes
64 bytes from muc11s02-in-x0d.1e100.net (2a00:1450:4016:801::200d): icmp_seq=1 ttl=55 time=7.31 ms
[root@centos ~]# ping6 www.googleapis.com
PING www.googleapis.com(fra16s14-in-x0a.1e100.net (2a00:1450:4001:81a::200a)) 56 data bytes
64 bytes from fra16s14-in-x0a.1e100.net (2a00:1450:4001:81a::200a): icmp_seq=1 ttl=58 time=0.848 ms
If the IPv6 is enabled and active, you should disable it.
sysctl -w net.ipv6.conf.all.disable_ipv6=1
sysctl -w net.ipv6.conf.default.disable_ipv6=1
For scanning from an AWS Outposts, you should use the PowerShell tool to disable the IPv6. Perform the following steps:
- Open the PowerShell as administrator.
- Execute the command to get all the network adapter names with IPv6 enabled:
Get-NetAdapterBinding -ComponentID ms_tcpip6
- Next, execute the below command to disable IPv6 on a specific network adapter. Replace “NetAdapterName” with the actual network adapter name you got with the earlier command.
Disable-NetAdapterBinding -Name "NetAdapterName" -ComponentID ms_tcpip6
(Optional) To turn off IPv6 on all network adapters, use the below PowerShell command:
Disable-NetAdapterBinding -Name "*" -ComponentID ms_tcpip6
- Close the PowerShell window.