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 Helix 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.
You can access and configure 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 Helix 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:
Creating a credential
To perform discovery on GCP, you should provide an access key (credential) with the help of which BMC Helix 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 Helix Discovery.
To create an Access Key in the IAM console:
- Create a new service account used for discovery users with the Viewer role, which provides 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 import it when you create a cloud credential in BMC Helix 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 Helix Discovery cloud credential. It would help if you kept 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 the cloud resource manager:
Creating a cloud credential in BMC Helix 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.
- Click Add on the BMC Helix Discovery Device Credentials page 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:
- Label
- Description
- Add the Service Account Key.
- (Optional) Specify a proxy to use to access. To use a proxy, you must specify the following:
- Hostname
- Port
- Username (only for authenticating proxies)
- Password (only for authenticating proxies)
The TLS Certificate Check option can be disabled if your proxy uses self-signed certificates.
Warning
If you disable the certificate check, your credentials could be intercepted by a man-in-the-middle attack.
- Click Apply.
Testing 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 copy the secret access key correctly. Also, you should ensure that the appliance time is no longer than five minutes of the time GCP uses. See Time setting for more information.
The BMC Helix Discovery appliance must be able to access GCP using HTTPS (port 443).
Time setting
Time synchronization is essential. You need to ensure that your appliance time is synchronized using NTP. If you do not use NTP, ensure the time is no further than five minutes from when GCP is used. GCP uses timestamped authentication, and any discrepancy will result in authentication failures.
Running 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 typically scheduled discovery runs.
- Select Cloud.
- Select Google Cloud Platform from the provider's 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 All.
- Click OK.
Examining results
Once you have scanned it, you can check the results as it is represented below:
The following screen represents a BMC Helix Discovery view of the scanned results:
Scanning the hosts running the VMs in the cloud
Perform a regular 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. It would help if you disabled "Ping before scanning", otherwise, all scans are dropped, reporting no response.
Database discovery
You can discover all supported databases in GCP. At the time of the release of BMC Helix Discovery 11.3, the following are supported:
- MySQL
- PostgreSQL
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 Helix 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 Helix Discovery is running on and be a part of a security group with a rule to allow access from the IP address BMC Helix Discovery connects to.
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 that enable the BMC Helix Discovery appliance to access the database. This depends on how 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—77.168.1.100/32
Then, the database can be discovered as any of your other MySQL databases.
BMC Helix Discovery database credential
Note
To discover a Database, 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 in the Pattern modules list under Cloud > Google Cloud Platform.
GCP labels discovery
GCP labels are modeled as tag attributes. For more information, see Discovering Cloud Tags
Time out issue
Time out error while scanning on Virtual Machine
The "time out" error could appear during a 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.
First, check if IPv6 is enabled. For that, execute a command:
ifconfig
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 IPv6 is enabled and active, you should disable it.
For scanning on VM, if accounts.google.com and www.googleapis.com are not accessible, execute the commands:
sysctl -w net.ipv6.conf.all.disable_ipv6=1
sysctl -w net.ipv6.conf.default.disable_ipv6=1
It would help if you used the PowerShell tool to disable the IPv6 for scanning from AWS Outposts. 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.
Comments
Log in or register to comment.