Prepare to deploy NetApp Console in restricted mode
Suggest changes
PDFs
Prepare your environment before you deploy NetApp Console in restricted mode. You need to review host requirements, prepare networking, set up permissions, and more.
Step 1: Understand how restricted mode works
Understand how the NetApp Console works in restricted mode before starting.
Use the browser-based interface available locally from the installed NetApp Console agent. You can't access the NetApp Console from the web-based console that's provided through the SaaS application.
In addition, not all Console features and NetApp data services are available.
Step 2: Choose a restricted-mode installation method
In restricted mode, you can install the Console agent in the cloud and access the NetApp Console through the locally installed agent. You can install through a cloud marketplace (AWS or Azure only) or manually on your own Linux host running in AWS, Azure, or Google Cloud.
-
From the AWS Marketplace
-
From the Azure Marketplace
-
Manually installing the Console agent on your own Linux host running in AWS, Azure, or Google Cloud
You must install the Console agent manually on a dedicated Linux host if deploying in Google Cloud.
Step 3: Review Console agent host requirements
When you deploy the Console agent from the AWS or Azure Marketplace, the image includes the required OS and software components. You simply need to choose an instance type that meets CPU and RAM requirements.
If you are installing manually on your own Linux host, ensure that the host meets the required OS, RAM, and port requirements.
- Dedicated host
-
The Console agent requires a dedicated host. Any architecture is supported if it meets these size requirements:
-
CPU: 8 cores or 8 vCPUs
-
RAM: 32 GB
-
Disk space: 165 GB is recommended for the host, with the following partition requirements:
-
/opt: 120 GiB of space must be availableThe agent uses
/optto install the/opt/application/netappdirectory and its contents. -
/var: 40 GiB of space must be availableThe Console agent requires this space in
/varbecause Podman or Docker is architected to create the containers within this directory. Specifically, they will create containers in the/var/lib/containers/storagedirectory and/var/lib/dockerfor Docker. External mounts or symlinks do not work for this space.
-
-
- AWS EC2 instance type
-
An instance type that meets CPU and RAM requirements. NetApp recommends t3.2xlarge.
- Azure VM size
-
An instance type that meets CPU and RAM requirements. NetApp recommends Standard_D8s_v3.
- Google Cloud machine type
-
An instance type that meets CPU and RAM requirements. NetApp recommends n2-standard-8.
The Console agent is supported in Google Cloud on a VM instance with an OS that supports Shielded VM features
- Hypervisor
-
A bare metal or hosted hypervisor that is certified to run a supported operating system is required.
- Operating system and container requirements
-
The Console agent is supported with the following operating systems when using the Console in standard mode or restricted mode. A container orchestration tool is required before you install the agent.
| Operating system | Supported OS versions | Supported agent versions | Required container tool | SELinux |
|---|---|---|---|---|
Red Hat Enterprise Linux |
9.6
|
4.0.0 or later with the Console in standard mode or restricted mode |
Podman version 5.4.0 with podman-compose 1.5.0. |
Supported in enforcing mode or permissive mode |
9.1 to 9.4
|
3.9.50 or later with the Console in standard mode or restricted mode |
Podman version 4.9.4 with podman-compose 1.5.0. |
Supported in enforcing mode or permissive mode |
|
8.6 to 8.10
|
3.9.50 or later with the Console in standard mode or restricted mode |
Podman version 4.6.1 or 4.9.4 with podman-compose 1.0.6. |
Supported in enforcing mode or permissive mode |
|
Ubuntu |
24.04 LTS |
3.9.45 or later with the NetApp Console in standard mode or restricted mode |
Docker Engine 23.0.6 to 28.0.0. |
Not supported |
22.04 LTS |
3.9.50 or later |
Docker Engine 23.0.6 to 28.0.0. |
Not supported |
Step 4: Prepare Podman or Docker Engine for manual installation
For manual installations, install and configure Podman or Docker Engine by following the instructions in the manual installation topic.
Step 5: Prepare network access for restricted mode
Set up network access so the Console agent can manage resources in your public cloud. In addition to having a virtual network and subnet for the Console agent, you need to ensure that the following requirements are met.
- Connections to target networks
-
Ensure the Console agent has a network connection to the storage locations. For example, the VPC or VNet where you plan to deploy Cloud Volumes ONTAP, or the data center where your on-premises ONTAP clusters reside.
- Prepare networking for user access to NetApp Console
-
In restricted mode, users access the Console's local interface from a browser connected to the Console agent VM. When users complete certain actions in the Console, their browser must be able to reach the endpoints listed below.
|
|
Console agents previous to version 4.0.0 support different endpoints. If you upgraded to 4.0.0 or later, you can remove the old endpoints from your allow list. Learn more about the required network access for versions previous to 4.0.0. |
| Endpoints | Purpose |
|---|---|
|
To provide features and services within the NetApp Console. |
https://services.cloud.netapp.com |
|
Outbound internet access for day-to-day operations
The Console agent needs outbound internet access to manage resources in your cloud provider and use NetApp Console services. Allow the endpoints for your environment and the shared Console services below.
AWS environments
Allow these AWS service endpoints to manage AWS resources, including FSx for ONTAP.
| Endpoints | Purpose |
|---|---|
AWS services (amazonaws.com):
|
To manage AWS resources. The endpoint depends on your AWS region. Refer to AWS documentation for details |
Amazon FSx for NetApp ONTAP:
|
The web-based console contacts this endpoint to interact with the Workload Factory APIs to manage and operate FSx for ONTAP-based workloads. |
Azure environments
Allow the endpoints that apply to your Azure region: public, Government, or China.
| Endpoints | Purpose |
|---|---|
|
To manage resources in Azure public regions. |
|
To manage resources in Azure Government regions. |
|
To manage resources in Azure China regions. |
- Public IP address in Azure
-
If you want to use a public IP address with the Console agent VM in Azure, the IP address must use a Basic SKU to ensure that the Console uses this public IP address.
If you use a Standard SKU IP address instead, then the Console uses the private IP address of the Console agent, instead of the public IP. If the machine that you're using to access the Console doesn't have access to that private IP address, then actions from the Console will fail.
Google Cloud environments
Allow these Google Cloud API endpoints to manage resources in your project.
| Endpoints | Purpose |
|---|---|
|
To manage resources in Google Cloud. |
NetApp Console endpoints
Allow the shared endpoints for NetApp Support, Console features, and Console agent deployment and upgrades.
| Endpoints | Purpose |
|---|---|
|
To obtain licensing information and to send AutoSupport messages to NetApp Support. |
|
To update NetApp Support Site (NSS) credentials or to add new NSS credentials to the NetApp Console. |
|
To obtain licensing information and to send AutoSupport messages to NetApp Support as well as to receive software updates for Cloud Volumes ONTAP. |
|
To provide features and services within the NetApp Console. |
For non-Government regions, use the following endpoints:
For Government regions, use the following endpoint instead:
|
To obtain images for Console agent deployment and upgrades. |
- 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 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.
Step 6: Prepare cloud provider permissions
The Console agent requires permissions from your cloud provider to deploy Cloud Volumes ONTAP in a virtual network and to use NetApp data services. You need to set up permissions in your cloud provider and then associate those permissions with the Console agent.
To view the required steps, choose the authentication option to use for your cloud provider.
Use an IAM role to provide the Console agent with permissions.
If you're creating the Console agent from the AWS Marketplace, you are prompted to select that IAM role when you launch the EC2 instance.
If you're manually installing the Console agent on your own Linux host, attach the role to the EC2 instance.
-
Log in to the AWS console and navigate to the IAM service.
-
Create a policy:
-
Select Policies > Create policy.
-
Select JSON and copy and paste the contents of the IAM policy for the Console agent.
-
Finish the remaining steps to create the policy.
-
-
Create an IAM role:
-
Select Roles > Create role.
-
Select AWS service > EC2.
-
Add permissions by attaching the policy that you just created.
-
Finish the remaining steps to create the role.
-
You now have an IAM role for the Console agent EC2 instance.
Set up permissions and an access key for an IAM user. You'll need to provide the Console with the AWS access key after you install the Console agent and set up the Console.
-
Log in to the AWS console and navigate to the IAM service.
-
Create a policy:
-
Select Policies > Create policy.
-
Select JSON and copy and paste the contents of the IAM policy for the Console agent.
-
Finish the remaining steps to create the policy.
Depending on the NetApp data services that you plan to use, you might need to create a second policy.
For standard regions, the permissions are spread across two policies. Two policies are required due to a maximum character size limit for managed policies in AWS. Learn more about IAM policies for the Console agent.
-
-
Attach the policies to an IAM user.
-
Ensure that the user has an access key that you can add to the NetApp Console after you install the Console agent.
Create an Azure custom role with the required permissions. You'll assign this role to the Console agent VM.
Note that you can create an Azure custom role using the Azure portal, Azure PowerShell, Azure CLI, or REST API. The following steps show how to create the role using the Azure CLI. If you would prefer to use a different method, refer to Azure documentation.
-
If you're planning to manually install the software on your own host, enable a system-assigned managed identity on the VM so that you can provide the required Azure permissions through a custom role.
-
Copy the contents of the custom role permissions for the Console agent and save them in a JSON file.
-
Modify the JSON file by adding Azure subscription IDs to the assignable scope.
You should add the ID for each Azure subscription that you want to use with the NetApp Console.
Example
"AssignableScopes": [ "/subscriptions/d333af45-0d07-4154-943d-c25fbzzzzzzz", "/subscriptions/54b91999-b3e6-4599-908e-416e0zzzzzzz", "/subscriptions/398e471c-3b42-4ae7-9b59-ce5bbzzzzzzz" ] -
Use the JSON file to create a custom role in Azure.
The following steps describe how to create the role by using Bash in Azure Cloud Shell.
-
Start Azure Cloud Shell and choose the Bash environment.
-
Upload the JSON file.
-
Use the Azure CLI to create the custom role:
az role definition create --role-definition agent_Policy.json
-
Create and set up a service principal in Microsoft Entra ID and obtain the Azure credentials that the Console needs. You need to provide the Console with these credentials after you install the Console agent.
-
Ensure that you have permissions in Azure to create an Active Directory application and to assign the application to a role.
For details, refer to Microsoft Azure Documentation: Required permissions
-
From the Azure portal, open the Microsoft Entra ID service.
-
In the menu, select App registrations.
-
Select New registration.
-
Specify details about the application:
-
Name: Enter a name for the application.
-
Account type: Select an account type (any will work with the NetApp Console).
-
Redirect URI: You can leave this field blank.
-
-
Select Register.
You've created the AD application and service principal.
-
Create a custom role:
Note that you can create an Azure custom role using the Azure portal, Azure PowerShell, Azure CLI, or REST API. The following steps show how to create the role using the Azure CLI. If you would prefer to use a different method, refer to Azure documentation
-
Copy the contents of the custom role permissions for the Console agent and save them in a JSON file.
-
Modify the JSON file by adding Azure subscription IDs to the assignable scope.
You should add the ID for each Azure subscription from which users will create Cloud Volumes ONTAP systems.
Example
"AssignableScopes": [ "/subscriptions/d333af45-0d07-4154-943d-c25fbzzzzzzz", "/subscriptions/54b91999-b3e6-4599-908e-416e0zzzzzzz", "/subscriptions/398e471c-3b42-4ae7-9b59-ce5bbzzzzzzz" ] -
Use the JSON file to create a custom role in Azure.
The following steps describe how to create the role by using Bash in Azure Cloud Shell.
-
Start Azure Cloud Shell and choose the Bash environment.
-
Upload the JSON file.
-
Use the Azure CLI to create the custom role:
az role definition create --role-definition agent_Policy.jsonYou should now have a custom role called Console Operator that you can assign to the Console agent virtual machine.
-
-
-
Assign the application to the role:
-
From the Azure portal, open the Subscriptions service.
-
Select the subscription.
-
Select Access control (IAM) > Add > Add role assignment.
-
In the Role tab, select the Console Operator role and select Next.
-
In the Members tab, complete the following steps:
-
Keep User, group, or service principal selected.
-
Select Select members.
-
Search for the name of the application.
Here's an example:
-
Select the application and select Select.
-
Select Next.
-
-
Select Review + assign.
The service principal now has the required Azure permissions to deploy the Console agent.
If you want to deploy Cloud Volumes ONTAP from multiple Azure subscriptions, then you must bind the service principal to each of those subscriptions. In the NetApp Console, you can select the subscription that you want to use when deploying Cloud Volumes ONTAP.
-
-
In the Microsoft Entra ID service, select App registrations and select the application.
-
Select API permissions > Add a permission.
-
Under Microsoft APIs, select Azure Service Management.
-
Select Access Azure Service Management as organization users and then select Add permissions.
-
In the Microsoft Entra ID service, select App registrations and select the application.
-
Copy the Application (client) ID and the Directory (tenant) ID.
When you add the Azure account to the Console, you need to provide the application (client) ID and the directory (tenant) ID for the application. The Console uses the IDs to programmatically sign in.
-
Open the Microsoft Entra ID service.
-
Select App registrations and select your application.
-
Select Certificates & secrets > New client secret.
-
Provide a description of the secret and a duration.
-
Select Add.
-
Copy the value of the client secret.
Your service principal is now set up and you should have copied the application (client) ID, the directory (tenant) ID, and the value of the client secret. You need to enter this information in the Console when you add an Azure account.
Create a role and apply it to a service account that you'll use for the Console agent VM instance.
-
Create a custom role in Google Cloud:
-
Create a YAML file that includes the permissions defined in the Console agent policy for Google Cloud.
-
From Google Cloud, activate cloud shell.
-
Upload the YAML file that includes the required permissions for the Console agent.
-
Create a custom role by using the
gcloud iam roles createcommand.The following example creates a role named "agent" at the project level:
gcloud iam roles create agent --project=myproject --file=agent.yaml
-
-
Create a service account in Google Cloud:
-
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 service account.
-