Authors: Diane Patton, NetApp
Roop Tyagi, Google
In the realm of data storage, security stands as an unwavering sentinel, guarding our sensitive information with utmost diligence. The stakes are high, and the consequences of accidental or intentional data copying or deletion can be catastrophic. A single misstep can unleash a tempest of business woes, tarnishing reputations and inflicting formidable financial losses. Therefore, it is of paramount importance to fortify sensitive data, ensuring that it remains securely locked away, impervious to the prying eyes, thieving hands, and unauthorized access of individuals. By erecting robust defenses, we safeguard against potential calamities and uphold the integrity of our valuable assets.
Although data plane protections such as firewalls, export policies, and file permissions, along with Identity and Access Management (IAM) do provide data security, they might not be a bulletproof solution. They may help prevent direct access to the volume from insecure networks or virtual machines, but they won’t prevent someone accessing the Google Cloud NetApp Volumes service API with a stolen password and deleting or replicating data to another service or location. This is where Google Cloud Virtual Private Cloud Service Controls (VPC SC) comes in.
VPC SC granularly controls API access to specific Google services, including Google Cloud NetApp Volumes, and is independent of IAM. It completes the picture of a fully secure environment by allowing control plane API access only to a service coming from specific services or locations identified by you, regardless of IAM.
This blog discusses VPC SC and how it works with Google Cloud NetApp Volumes.
Tell me more about Google Cloud VPC SC
Users and other services or applications generally access a specific Google service API to make changes and retrieve information. Because Google APIs generally have public endpoints, they can be accessed from the internet, from corporate IP addresses, and by other Google services. This means that if any user or service has the proper credentials and can access the API, they can make changes to that service. VPC SC limits that capability by essentially providing an API firewall for Google APIs and controls API access to various Google services.
Specific Google services APIs can be protected by implementing a VPC SC perimeter around them. When this perimeter is put into place, you control who or what can cross the perimeter to access that service API. Here are a few examples:
- You would like to allow a specific user to configure a service, but only from a machine with a corporate IP address. The same user cannot access the API from a coffee shop, for example.
- You might want to allow a machine outside the perimeter read/write access but not allow it to make any changes to the volume.
- You might need to allow only one service from a specific project to have API access to another service from another project in a different perimeter, but no others. This can be accomplished by using ingress/egress rules. If all services are allowed to communicate with each other between projects, this can also be accomplished by using a perimeter bridge.
All of these operations, and many more, can be accomplished with VPC SC.
Because VPC SC works on the service control plane, it is considered to be project based, not VPC based. It cannot block traffic flowing over virtual networks like a firewall can, and it cannot control who can NFS mount like export policies can. It can only affect restrictions to API endpoints on supported services. It can also affect access to data on object store services because data in object store is accessed via the API, but it does not affect access to data accessible by the NAS protocols NFS or SMB.
How would VPC SC be deployed with NetApp Volumes?
VPC SC is supported with Google Cloud Netapp Volumes. Deploying VPC SC with NetApp Volumes does not eliminate the need to implement data plane security measures such as firewalls, NFS export policies, file permissions, and so on for the NAS-based protocols NFS and/or SMB. The following figure shows the difference between the control plane with API access and the data plane with NFS and SMB.
NetApp Volumes NFS and SMB endpoints are accessible from services within defined Google Cloud VPCs. They don’t have public API endpoints accessible from the internet. Unless you add VPNs or interconnects, you cannot mount from a VM on a different VPC or connect from the internet, which makes them inherently secure. You can control who can mount a share on an NFS server by using NFS export policies., And you can control who sees the share by using NFSv4.1 ACLs and SMB share access controls. Additionally, SMB supports other data plan security features such as access-based enumeration and hide SMB share.
VPC SC can be used to control who (by IP address) or what (by service) can access the Google Cloud NetApp Volumes control plane to configure or retrieve information. These actions can be done by using ingress/egress rules and can be filtered down to individual NetApp Volumes APIs. IAM is still used for user identity.
In the following example, we put NetApp Volumes and Google Cloud Storage in its own service perimeter, requiring all API access to be controlled. Communication between NetApp Volumes and Google Cloud storage APIs is not restricted and is required for backup and auto-tiering. All volume management services that reside outside the perimeter and use API requests, including the Google Cloud console, will need to be allowed through with ingress/egress rules. However, the machines coming from the Compute Engine or Kubernetes Engine that need to mount and read/write a volume using NFS or SMB will be let through, provided that they have a route to NetApp volumes and are accepted through the data plane security features such as export policies.
VPC SC can also restrict access based on where the request originates from. In the following figure, access is allowed from inside the corporate network, but not from anywhere else on the internet.
For persistent Kubernetes applications, NetApp Trident™ requires API access to retrieve required information and create volumes.
If you trust Google Kubernetes Engine and Compute Engine Services, you can also place both of those (or any other supported Google services) within the perimeter. In that case, you don’t have to configure ingress/egress rules for them. It’s entirely up to you.
Now what?
Now that you have a basic understanding of VPC SC with NetApp Volumes, read more about it. Try it out in dry-run mode to get some information and logs on the required communications without creating any blocking. Then implement VPC SC to limit access to NetApp Volumes API as part of a comprehensive security solution for your cloud environment.
