Storage
Mobility
Protection
Analysis and control
TOPICShare
Keeping workloads safe in the cloud entails end-to-end security of the entire application stack, starting with the compute resources, over the network, and—most importantly—at the storage layer. Data breaches can have far-reaching consequences, which makes security a top priority for organizations hosting their mission-critical applications using Google Cloud storage.
Cloud Volumes ONTAP brings the capabilities of NetApp’s popular ONTAP solution to Google Cloud, which eases the storage lifecycle management all the while ensuring comprehensive security of your data. In this blog we will explore the necessary configurations required for secure deployment of Cloud Volumes ONTAP in Google Cloud.
Use the links below to jump down to:
Secure Deployment of Cloud Volumes ONTAP in GCP
Cloud Volumes ONTAP helps organizations get maximum ROI from their Google Cloud deployments thanks to NetApp’s proprietary capabilities for storage efficiency, flexibility, data protection, visibility, and security. These can be key tools in performing a Google Cloud migration, ensuring Google Cloud backup, and optimizing Google Cloud pricing.
In addition to delivering a storage layer augmented with advanced NetApp ONTAP features, Cloud Volumes ONTAP also integrates multiple native Google Cloud services to ensure data security. This includes segregation and protection through VPC, data encryption, secure key management, and more. The control plane is also secured using Google Cloud IAM roles.
In this section we’ll give you a step-by-step guide on how to use these features and ensure a secure deployment for Cloud Volumes ONTAP in Google Cloud.
1. IAM Configuration
Your IAM configuration will involve three components: setting up custom roles, setting up your service account, and defining organizational policies.
1.1. Custom Roles
Cloud Volumes ONTAP should be deployed using the principle of least privilege so that its components and users have only the minimum rights required to use the service.
A connector should be deployed by an account with the right permissions so that NetApp BlueXP Console can centrally access and manage Cloud Volumes ONTAP resources. The connector deployment uses a custom role for this operation.
Google Cloud provides predefined roles for fine-grained access control and security. However, custom roles should be considered where the predefined roles might end up giving permissions that are more than what a user need.
To abide by the principle of least privilege, Cloud Volumes ONTAP deployment will use a custom role for the connector deployment which is created using a yaml file. The yaml file can be deployed from the gcloud command-line tool.
1.1.1. Upload the yaml file to the gcloud command-line tool.
1.1.2. Run the following command to create the custom role:
gcloud iam roles create <<role-id>> --project=<<GCP project id>> --file=<<Path to yaml file>>
Replace role-id with the name of the role. Also update the value of GCP project id and YAML file path as appropriate to your environment. A sample command is shown below:
1.1.3. If you get a message about APIs not being enabled with a prompt to enable the APIs, type in response as Y.
1.1.4. Once the role is created successfully, you will get a confirmation message:
1.1.5. In this step, assign the custom role created to the right user who will deploy the NetApp BlueXP Console from NetApp BlueXP.
From the Google Cloud console, browse to IAM & Admin -> IAM -> Add. Provide the name of the user and select the newly created custom role and save the role assignment.
1.2. Service Accounts
Service accounts are special accounts that are used by applications or resources like VMs to access other cloud resources. Service accounts are assigned IAM roles and that determines the resources the applications are authorized to access. In this way service accounts act indirectly as the identity of the application itself.
This is a highly secure way of storing credentials since the virtual machine inside Google Cloud makes calls to the APIs and authenticates directly with GCP inside the perimeter without having to store JSON key files anywhere.
The secure deployment process needs a service account that will be used by BlueXP Console to deploy Cloud Volumes ONTAP instances in your GCP project. Download the BlueXP Console IAMpolicy yaml file that will be used to create a custom role for the service account with required permissions, then upload it to gcloud command-line environment
1.2.1. Run the following command to create the custom role for the BlueXP Console service account:
gcloud iam roles create <<role-id>> --project=<<GCP project id>> --file=<<Path to yaml file>>
Replace role-id with the name of the role for BlueXP Console. Also update the value of GCP project id and Path to yaml file with the appropriate information for your environment.
A sample command for this is shown below:
1.2.2. You will get a confirmation message when the role is created.
1.2.3. Create a service account for BlueXP Console by browsing to IAM & Admin -> Service accounts -> +Create Service Account.
1.2.4. Provide account name and click “Create and Continue.”
1.2.5. Assign the custom role “NetApp BlueXP Console” to the service account and click on “Done” to proceed.
1.3. Organizational Policies
You also have the option to implement additional security constraints in Google Cloud through organizational policies. The organizational policies ensure that the Cloud Volumes ONTAP environment has organizational compliance-related guardrails built around it.
Organization policies can be used to implement constraints related to using service accounts and locating Cloud Volumes ONTAP resources. For example, an organization policy can be implemented that will restrict Cloud Volumes ONTAP deployment to a specific region if there are data residency requirements to be met.
To deploy Cloud Volumes ONTAP through BlueXP Console, there are some organizational policy exceptions that must be made for the workflow to complete as designed. These are grouped by exceptions required to deploy BlueXP Console through gcloud and exceptions required to deploy Cloud Volumes ONTAP from BlueXP Console:
- Exceptions for deploying connector using BlueXP Console image:
- constraints/gcp.resourceLocations:
- Must allow:
- Location deploying instances, e.g. us-east4-locations
- Must allow:
- constraints/compute.restrictNonConfidentialComputing
- Must allow:
- googleapis.com
- Must allow:
- constraints/compute.requireShieldedVm
- Not Enforced for any NetApp VMs
- constraints/compute.trustedImageProjects
- Must allow:
- projects/netapp-cloudmanager
- Must allow:
- constraints/gcp.resourceLocations:
- Exceptions for deploying Cloud Volumes ONTAP from BlueXP Console:
- constraints/compute.disableSerialPortLogging
- Not Enforced for any NetApp Cloud Volumes ONTAP VMs
- constraints/compute.restrictLoadBalancerCreationForTypes
- Allow: INTERNAL_TCP_UDP in service project
- constraints/compute.disableSerialPortLogging
2. Network Security
In this section we’ll look at the network security parameters to consider in your deployment.
2.1. VPC Segregation
VPCs in Google Cloud can be considered a security perimeter. They are global resources and each VPC can have multiple subnets, each of which are regional resources. Resources deployed in a VPC are segregated and cannot communicate with each other by default.
Users can also create shared VPCs in Google Cloud—a unique concept in Google Cloud where resources from multiple projects can be connected to a common VPC. One project is designed as a host project with multiple service projects attached to it. Shared VPCs enable secure communication between resources in different projects using internal IPs.
Cloud Volumes ONTAP deployment needs one VPC for Single node deployment and 4 VPCs for HA deployment with a private subnet in each VPC. These VPCs can either be standalone or shared VPCs. While using Shared VPC, ensure that the “Compute Network User” IAM role is assigned to the BlueXP Console service account created in the previous section. This role provides necessary permissions for BlueXP Console to query network resources such as VPCs, subnets, and firewalls in the host project. For a full list of permissions for all of the service accounts, please refer to the permissions table in the BlueXP Console documentation.
2.2. Private Google Access
To use the data tiering feature of Cloud Volumes ONTAP, the subnet in which the connector is deployed should have Private Google Access enabled.
Private Google Access enables access to Google APIs and services through the Google Cloud network backbone from the connector subnet without exposing an external IP. This ensures a secure connection between Cloud Volumes ONTAP and Google Cloud services for data tiering. Private Google Access can be enabled by setting the “Private Google Access” toggle to “on” while creating the subnet.
2.3. VPC Service Controls
Customers can enable VPC Service Controls to enable access to define a security perimeter for workloads in Google Cloud and restrict access to resources from only allowed identities/IP addresses/devices. This helps in protecting sensitive data in your application by preventing any exfiltration attempts to API controlled resources.
Since Cloud Volumes ONTAP only supports NAS and SAN protocols and not API-driven data access like object storage, VPC Service Controls are not required for ONTAP data access—that is all handled at the application and/or protocol layer. VPC Service Controls are used in conjunction with the BlueXP Console connector to ensure that all calls made from the connector are authorized and supported within the organization service perimeter.
If your VPC is secured using VPC service controls, you should add ingress and egress rules to allow required communication to pull images from the NetApp project with the projectId netapp-cloudmanager and the project number 14190056516. This is for pulling and deploying the required images during Cloud Volumes ONTAP configuration. You can review the ingress rule and egress rule references to create the VPC service control perimeter policy for Cloud Volumes ONTAP.
2.4. Firewall Rules
Firewall rules in Google Cloud ensure that only allowed ingress and egress traffic traverses the network. These rules add an additional layer of security for workloads connected to Google Cloud VPC. During the Cloud Volumes ONTAP deployment process BlueXP Console creates the required ingress and egress rules for the services to operate. Check out this post on Cloud Volumes ONTAP high availability in Google Cloud to learn more.
By default all outbound traffic is allowed but customers can further reduce allowed outbound traffic by creating more stringent egress rules. The connector deployment also gives an option to create firewall rules with required ingress traffic over HTTP, HTTPS, and SSH ports. The egress rules are permissive, but can be made further fine grained by creating advanced outbound rules that allow only the traffic required by the connector.
2.5. Outbound Internet Access from the BlueXP Console Connector
The BlueXP Console connector is the powerhouse of the NetApp experience and is intrinsically linked to the NetApp BlueXP Console SaaS platform. To make all that possible, the VM that hosts the connector software requires outbound internet access.
The primary reasons for this outbound access are authentication and access to NetApp services such as support, Cloud Backup service, Cloud Tiering service, Cloud Sync, Cloud Data Sense, and the BlueXP Console Account services. Outbound access is also required to maintain the most recent versions of BlueXP Console through the automatic update service implemented with all modern BlueXP Console connector software deployments, which are managed by Docker.
A full list of the endpoints that are required to be reachable are listed in the BlueXP Console documentation. Keep looking for the most recent lists, since we are always working to reduce the list of required endpoints and consolidate services.
For secure environments, external access is always tightly controlled; BlueXP Console can fall in line with network security policies by working through a proxy for its external access. Proxy information can be passed to the BlueXP Console connector either during deployment, or locally through the user interface during set up. To keep all Google Cloud traffic internal, there is also an option within BlueXP Console to bypass the proxy with all traffic destined to Google Cloud APIs.
3. Data Encryption
Data stored in Google Cloud is always encrypted by default through Google-managed encryption. However, customers also have the flexibility to use a key of their choice through customer-supplied encryption keys or customer-managed encryption keys.
Cloud Volumes ONTAP supports encryption of data using customer-managed encryption keys generated and managed in Google Cloud Key Management Service (KMS). KMS is a managed hosted key management service from Google Cloud that can be used to create/manage cryptographic keys. It supports strong encryption ciphers such as AES-256, RSA 2048/3072/4096, and EC P384/P384. Leveraging customer-managed encryption keys in KMS for Cloud Volumes ONTAP ensures that you have full control over the data encryption process, thereby ensuring comprehensive security of data stored in Cloud Volumes ONTAP volumes.
To use customer-managed encryption keys with Cloud Volumes ONTAP, the following KMS permissions are required for BlueXP Console connector service account accessing the keys:
- cloudkms.cryptoKeyVersions.useToEncrypt
- cloudkms.cryptoKeys.get
- cloudkms.cryptoKeys.list
- cloudkms.keyRings.list
These permissions are already assigned to the NetApp BlueXP Console service account we created in the IAM configuration section above, but may need to be added separately if the keys to be used are stored in a different project. To create an encryption key for KMS to be used with Cloud Volumes ONTAP, execute the following steps:
3.1. Browse to the KMS service in Google Cloud console:
3.2. Enable the API, if it is not already enabled.
3.3. Click on “+CREATE KEY RING.”
3.4. Provide the name and location of the key ring. Both Regional and Global keys are supported with Cloud Volumes ONTAP, but multi-regional keys are not currently supported.
Click on “CREATE”.
3.5. In the next step generate a key for Cloud Volumes ONTAP and also set the key rotation period.
Click on “CREATE” in the page to generate the key.
3.6. Browse to IAM & Admin -> IAM to get details of the default compute engine service account. This information is required to give the account permission to the Cloud Volumes ONTAP key.
3.7. Browse to KMS -> Key ring and select the Cloud Volumes ONTAP key created in Step 5. When you are done, click on “+ADD PRINCIPAL.”
3.8. Assign the default Compute Engine Service admin account we got from step 6 and the Cloud KMS Encrypter/Decrypter role to the Cloud Volumes ONTAP key.
Click on “SAVE.”
3.9. If you are using data tiering, you’ll also need to provide the KMS encrypter/decrypter permissions to the default cloud storage service account, since the same keys will be used for the process.
Note down the default storage account service account by browsing to Cloud storage -> Settings.
3.10. Assign the Cloud KMS encrypter/decrypter role on the Cloud Volumes ONTAP key to the default storage service admin account we got from step 8.
When you’re done, click on “SAVE.”
3.11. Browse to KMS -> Key ring and select the Cloud Volumes ONTAP key created in Step 5.
Click on the menu options on the left and select “Copy Resource Name.” This value will be used during automated Cloud Volumes ONTAP deployment to enable your customer-managed encryption key.
Here is a sample value of what that will look like:
projects/Netapp-demo/locations/us-central1/keyRings/CVO/cryptoKeys/cvokey
3.12. Use the value that you got in Step 10 for the gcpEncryption parameter while making API calls for Cloud Volumes ONTAP deployment.
A sample snippet is given below to show you what this should look like:
"gcpEncryptionParameters": {
"key": "projects/Netapp-demo/locations/us-central1/keyRings/CVO/cryptoKeys/cvokey"
}
3.13. If tiering is enabled during the deployment process, then the Google Cloud Storage bucket used to store the tiered dataset will also automatically be encrypted with the same key referenced in the deployment body.
The Next Step: Cloud Volumes ONTAP Deployment
We have reviewed the necessary configurations that you can implement to ensure that the data in Cloud Volumes ONTAP volumes are secure from ground up. These include enhanced security of the network through VPC features like firewall, private access, usage of IAM custom roles, and service accounts for access control as well as data encryption enabled by KMS.
For the next steps, you should follow the instructions in our Cloud Volumes ONTAP deployment blog for Google Cloud to get started. And read more about Cloud Volumes ONTAP’s security features here.
