Create a Console agent from Google Cloud
Suggest changes
PDFs
To create a Console agent in Google Cloud by using Google Cloud, you need to set up your networking, prepare Google Cloud permissions, enable Google Cloud APIs, and then create the Console agent.
-
You should have a understanding of Console agents.
-
You should review Console agent limitations.
Step 1: Set up networking
Set up networking to enable the Console agent to manage resources and connect to target networks and the internet.
- VPC and subnet
-
When you create the Console agent, you need to specify the VPC and subnet where it should reside.
- Connections to target networks
-
The Console agent requires a network connection to the location where you're planning to create and manage systems. For example, the network where you plan to create Cloud Volumes ONTAP systems or a storage system in your on-premises environment.
- Outbound internet access
-
The network location where you deploy the Console agent must have an outbound internet connection to contact specific endpoints.
- Endpoints contacted from the Console agent
-
The Console agent requires outbound internet access to contact the following endpoints to manage resources and processes within your public cloud environment for day-to-day operations.
The endpoints listed below are all CNAME entries.
Endpoints Purpose https://www.googleapis.com/compute/v1/
https://compute.googleapis.com/compute/v1
https://cloudresourcemanager.googleapis.com/v1/projects
https://www.googleapis.com/compute/beta
https://storage.googleapis.com/storage/v1
https://www.googleapis.com/storage/v1
https://iam.googleapis.com/v1
https://cloudkms.googleapis.com/v1
https://www.googleapis.com/deploymentmanager/v2/projectsTo manage resources in Google Cloud.
https://mysupport.netapp.com
To obtain licensing information and to send AutoSupport messages to NetApp support.
https://signin.b2c.netapp.com
To update NetApp Support Site (NSS) credentials or to add new NSS credentials to the NetApp Console.
https://support.netapp.com
To obtain licensing information and to send AutoSupport messages to NetApp support as well as to receive software updates for Cloud Volumes ONTAP.
https://api.bluexp.netapp.com
https://netapp-cloud-account.auth0.com
https://netapp-cloud-account.us.auth0.com
https://console.netapp.com
https://components.console.bluexp.netapp.com
https://cdn.auth0.comTo provide features and services within the NetApp Console.
https://bluexpinfraprod.eastus2.data.azurecr.io
https://bluexpinfraprod.azurecr.ioTo obtain images for Console agent upgrades.
-
When you deploy a new agent, the validation check tests connectivity to current endpoints. If you use previous endpoints, the validation check fails. To avoid this failure, skip the validation check.
Although the previous endpoints are still supported, NetApp recommends updating your firewall rules to the current endpoints as soon as possible. Learn how to update your endpoint list.
-
When you update to the current endpoints in your firewall, your existing agents will continue to work.
-
- Endpoints contacted from the NetApp console
-
As you use the web-based NetApp Console that's provided through the SaaS layer, it contacts several endpoints to complete data management tasks. This includes endpoints that are contacted to deploy the Console agent from the the Console.
- Proxy server
-
NetApp supports both explicit and transparent proxy configurations. If you are using a transparent proxy, you only need to provide the certificate for the proxy server. If you are using an explicit proxy, you'll also need the IP address and credentials.
-
IP address
-
Credentials
-
HTTPS certificate
-
- Ports
-
There's no incoming traffic to the Console agent, unless you initiate it or if it is used as a proxy to send AutoSupport messages from Cloud Volumes ONTAP to NetApp Support.
-
HTTP (80) and HTTPS (443) provide access to the local UI, which you'll use in rare circumstances.
-
SSH (22) is only needed if you need to connect to the host for troubleshooting.
-
Inbound connections over port 3128 are required if you deploy Cloud Volumes ONTAP systems in a subnet where an outbound internet connection isn't available.
If Cloud Volumes ONTAP systems don't have an outbound internet connection to send AutoSupport messages, the Console automatically configures those systems to use a proxy server that's included with the Console agent. The only requirement is to ensure that the Console agent's security group allows inbound connections over port 3128. You'll need to open this port after you deploy the Console agent.
-
- Enable NTP
-
If you're planning to use NetApp Data Classification to scan your corporate data sources, you should enable a Network Time Protocol (NTP) service on both the Console agent and the NetApp Data Classification system so that the time is synchronized between the systems. Learn more about NetApp Data classification
Implement this networking requirement after creating the Console agent.
Step 2: Set up permissions to create the Console agent
Set up permissions for the Google Cloud user to deploy the Console agent VM from Google Cloud.
-
Create a custom role in Google Platform:
-
Create a YAML file that includes the following permissions:
title: Console agent deployment policy description: Permissions for the user who deploys the NetApp Console agent stage: GA includedPermissions: - compute.disks.create - compute.disks.get - compute.disks.list - compute.disks.setLabels - compute.disks.use - compute.firewalls.create - compute.firewalls.delete - compute.firewalls.get - compute.firewalls.list - compute.globalOperations.get - compute.images.get - compute.images.getFromFamily - compute.images.list - compute.images.useReadOnly - compute.instances.attachDisk - compute.instances.create - compute.instances.get - compute.instances.list - compute.instances.setDeletionProtection - compute.instances.setLabels - compute.instances.setMachineType - compute.instances.setMetadata - compute.instances.setTags - compute.instances.start - compute.instances.updateDisplayDevice - compute.machineTypes.get - compute.networks.get - compute.networks.list - compute.networks.updatePolicy - compute.projects.get - compute.regions.get - compute.regions.list - compute.subnetworks.get - compute.subnetworks.list - compute.zoneOperations.get - compute.zones.get - compute.zones.list - deploymentmanager.compositeTypes.get - deploymentmanager.compositeTypes.list - deploymentmanager.deployments.create - deploymentmanager.deployments.delete - deploymentmanager.deployments.get - deploymentmanager.deployments.list - deploymentmanager.manifests.get - deploymentmanager.manifests.list - deploymentmanager.operations.get - deploymentmanager.operations.list - deploymentmanager.resources.get - deploymentmanager.resources.list - deploymentmanager.typeProviders.get - deploymentmanager.typeProviders.list - deploymentmanager.types.get - deploymentmanager.types.list - resourcemanager.projects.get - compute.instances.setServiceAccount - iam.serviceAccounts.list -
From Google Cloud, activate cloud shell.
-
Upload the YAML file that includes the required permissions.
-
Create a custom role by using the
gcloud iam roles createcommand.The following example creates a role named "connectorDeployment" at the project level:
gcloud iam roles create connectorDeployment --project=myproject --file=connector-deployment.yaml
-
-
Assign this custom role to the user who deploys the Console agent from Google Cloud.
Step 3: Set up permissions for the Console agent operations
A Google Cloud service account is required to provide the Console agent with the permissions that the Console needs to manage resources in Google Cloud. When you create the Console agent, you'll need to associate this service account with the Console agent VM.
It's your responsibility to update the custom role as new permissions are added in subsequent releases. If new permissions are required, they will be listed in the release notes.
-
Create a custom role in Google Cloud:
-
Create a YAML file that includes the contents of the service account permissions for the Console agent.
-
From Google Cloud, activate cloud shell.
-
Upload the YAML file that includes the required permissions.
-
Create a custom role by using the
gcloud iam roles createcommand.The following example creates a role named "connector" at the project level:
gcloud iam roles create connector --project=myproject --file=connector.yaml
-
-
Create a service account in Google Cloud and assign the role to the service account:
-
From the IAM & Admin service, select Service Accounts > Create Service Account.
-
Enter service account details and select Create and Continue.
-
Select the role that you just created.
-
Finish the remaining steps to create the role.
-
-
If you plan to deploy Cloud Volumes ONTAP systems in different projects than the project where the Console agent resides, then you'll need to provide the Console agent's service account with access to those projects.
For example, let's say the Console agent is in project 1 and you want to create Cloud Volumes ONTAP systems in project 2. You'll need to grant access to the service account in project 2.
-
From the IAM & Admin service, select the Google Cloud project where you want to create Cloud Volumes ONTAP systems.
-
On the IAM page, select Grant Access and provide the required details.
-
Enter the email of the Console agent's service account.
-
Select the Console agent's custom role.
-
Select Save.
-
For more details, refer to Google Cloud documentation
-
Step 4: Set up shared VPC permissions
If you are using a shared VPC to deploy resources into a service project, then you'll need to prepare your permissions.
This table is for reference and your environment should reflect the permissions table when IAM configuration is complete.
View shared VPC permissions
| Identity | Creator | Hosted in | Service project permissions | Host project permissions | Purpose |
|---|---|---|---|---|---|
Google account to deploy the agent |
Custom |
Service Project |
compute.networkUser |
Deploying the agent in the service project |
|
agent service account |
Custom |
Service project |
compute.networkUser |
Deploying and maintaining Cloud Volumes ONTAP and services in the service project |
|
Cloud Volumes ONTAP service account |
Custom |
Service project |
storage.admin |
N/A |
(Optional) For NetApp Cloud Tiering and NetApp Backup and Recovery |
Google APIs service agent |
Google Cloud |
Service project |
(Default) Editor |
compute.networkUser |
Interacts with Google Cloud APIs on behalf of deployment. Allows the Console to use the shared network. |
Google Compute Engine default service account |
Google Cloud |
Service project |
(Default) Editor |
compute.networkUser |
Deploys Google Cloud instances and compute infrastructure on behalf of deployment. Allows the Console to use the shared network. |
Notes:
-
deploymentmanager.editor is only required at the host project if you are not passing firewall rules to the deployment and are choosing to let the Console create them for you. The NetApp Console creates a deployment in the host project which contains the VPC0 firewall rule if no rule is specified.
-
firewall.create and firewall.delete are only required if you are not passing firewall rules to the deployment and are choosing to let the Console create them for you. These permissions reside in the Console account .yaml file. If you are deploying an HA pair using a shared VPC, these permissions will be used to create the firewall rules for VPC1, 2 and 3. For all other deployments, these permissions will also be used to create rules for VPC0.
-
For Cloud Tiering, the tiering service account must have the serviceAccount.user role on the service account, not just at the project level. Currently if you assign serviceAccount.user at the project level, the permissions don't show when you query the service account with getIAMPolicy.
Step 5: Enable Google Cloud APIs
Enable several Google Cloud APIs before deploying the Console agent and Cloud Volumes ONTAP.
-
Enable the following Google Cloud APIs in your project:
-
Cloud Deployment Manager V2 API
-
Cloud Logging API
-
Cloud Resource Manager API
-
Compute Engine API
-
Identity and Access Management (IAM) API
-
Cloud Key Management Service (KMS) API
(Required only if you are planning to use NetApp Backup and Recovery with customer-managed encryption keys (CMEK))
-
Step 6: Create the Console agent
Create a Console agent by using Google Cloud.
Creating the Console agent deploys a VM instance in Google Cloud with the default configuration. Do not switch to a smaller VM instance with fewer CPUs or less RAM after you create the Console agent. Learn about the default configuration for the Console agent.
You should have the following:
-
The required Google Cloud permissions to create the Console agent and a service account for the Console agent VM.
-
A VPC and subnet that meets networking requirements.
-
An understanding of VM instance requirements.
-
CPU: 8 cores or 8 vCPUs
-
RAM: 32 GB
-
Machine type: We recommend n2-standard-8.
The Console agent is supported in Google Cloud on a VM instance with an OS that supports Shielded VM features.
-
-
Log in to the Google Cloud SDK using your preferred method.
This example uses a local shell with the gcloud SDK installed, but you can also use the Google Cloud Shell.
For more information about the Google Cloud SDK, visit the Google Cloud SDK documentation page.
-
Verify that you are logged in as a user who has the required permissions that are defined in the section above:
gcloud auth listThe output should show the following where the * user account is the desired user account to be logged in as:
Credentialed Accounts ACTIVE ACCOUNT some_user_account@domain.com * desired_user_account@domain.com To set the active account, run: $ gcloud config set account `ACCOUNT` Updates are available for some Cloud SDK components. To install them, please run: $ gcloud components update -
Run the
gcloud compute instances createcommand:gcloud compute instances create <instance-name> --machine-type=n2-standard-8 --image-project=netapp-cloudmanager --image-family=cloudmanager --scopes=cloud-platform --project=<project> --service-account=<service-account> --zone=<zone> --no-address --tags <network-tag> --network <network-path> --subnet <subnet-path> --boot-disk-kms-key <kms-key-path>- instance-name
-
The desired instance name for the VM instance.
- project
-
(Optional) The project where you want to deploy the VM.
- service-account
-
The service account specified in the output from step 2.
- zone
-
The zone where you want to deploy the VM
- no-address
-
(Optional) No external IP address is used (you need a cloud NAT or proxy to route traffic to the public internet)
- network-tag
-
(Optional) Add network tagging to link a firewall rule using tags to the Console agent instance
- network-path
-
(Optional) Add the name of the network to deploy the Console agent into (for a Shared VPC, you need the full path)
- subnet-path
-
(Optional) Add the name of the subnet to deploy the Console agent into (for a Shared VPC, you need the full path)
- kms-key-path
-
(Optional) Add a KMS key to encrypt the Console agent's disks (IAM permissions also need to be applied)
For more information about these flags, visit the Google Cloud compute SDK documentation.
Running the command deploys the Console agent. The Console agent instance and software should be running in approximately five minutes.
-
Open a web browser and enter the Console agent host URL:
The Console host URL can be a localhost, a private IP address, or a public IP address, depending on the configuration of the host. For example, if the Console agent is in the public cloud without a public IP address, you must enter a private IP address from a host that has a connection to the Console agent host.
-
After you log in, set up the Console agent:
-
Specify the Console organization to associate with the Console agent.
-
Enter a name for the system.
-
The Console agent is now installed and set up with your Console organization.
Open a web browser and go to the NetApp Console to start using the Console agent.