Skip to main content
NetApp Console setup and administration

Create a Console agent in AWS from NetApp Console

Contributors netapp-tonias
PDFs

You can create a Console agent in AWS directly from the NetApp Console. Before creating a Console agent in AWS from the Console, you need to set up your networking and prepare AWS permissions.

Before you begin

Step 1: Set up networking for deploying a Console agent in AWS

Ensure that the network location where you plan to install the Console agent supports the following requirements. These requirements enable the Console agent to manage resources and processes in your hybrid cloud.

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

AWS services (amazonaws.com):

  • CloudFormation

  • Elastic Compute Cloud (EC2)

  • Identity and Access Management (IAM)

  • Key Management Service (KMS)

  • Security Token Service (STS)

  • Simple Storage Service (S3)

To manage AWS resources. The endpoint depends on your AWS region. Refer to AWS documentation for details

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://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.com

To provide features and services within the NetApp Console.

https://bluexpinfraprod.eastus2.data.azurecr.io
https://bluexpinfraprod.azurecr.io

To 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.

View the list of endpoints contacted from the NetApp 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

You'll need to implement this networking requirement after you create the Console agent.

Step 2: Set up AWS permissions for the Console agent

The Console needs to authenticate with AWS before it can deploy the Console agent instance in your VPC. You can choose one of these authentication methods:

  • Let the Console assume an IAM role that has the required permissions

  • Provide an AWS access key and secret key for an IAM user who has the required permissions

With either option, the first step is to create an IAM policy. This policy contains only the permissions needed to launch the Console agent instance in AWS from the Console.

If needed, you can restrict the IAM policy by using the IAM Condition element. AWS documentation: Condition element

Steps

  1. Go to the AWS IAM console.

  2. Select Policies > Create policy.

  3. Select JSON.

  4. Copy and paste the following policy:

    This policy contains only the permissions needed to launch the Console agent instance in AWS from the Console. When the Console creates the Console agent, it applies a new set of permissions to the Console agent instance that enables the Console agent to manage AWS resources. View permissions required for the Console agent instance itself.

    {
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "iam:CreateRole",
        "iam:DeleteRole",
        "iam:PutRolePolicy",
        "iam:CreateInstanceProfile",
        "iam:DeleteRolePolicy",
        "iam:AddRoleToInstanceProfile",
        "iam:RemoveRoleFromInstanceProfile",
        "iam:DeleteInstanceProfile",
        "iam:PassRole",
        "iam:ListRoles",
        "ec2:DescribeInstanceStatus",
        "ec2:RunInstances",
        "ec2:ModifyInstanceAttribute",
        "ec2:CreateSecurityGroup",
        "ec2:DeleteSecurityGroup",
        "ec2:DescribeSecurityGroups",
        "ec2:RevokeSecurityGroupEgress",
        "ec2:AuthorizeSecurityGroupEgress",
        "ec2:AuthorizeSecurityGroupIngress",
        "ec2:RevokeSecurityGroupIngress",
        "ec2:CreateNetworkInterface",
        "ec2:DescribeNetworkInterfaces",
        "ec2:DeleteNetworkInterface",
        "ec2:ModifyNetworkInterfaceAttribute",
        "ec2:DescribeSubnets",
        "ec2:DescribeVpcs",
        "ec2:DescribeDhcpOptions",
        "ec2:DescribeKeyPairs",
        "ec2:DescribeRegions",
        "ec2:DescribeInstances",
        "ec2:CreateTags",
        "ec2:DescribeImages",
        "ec2:DescribeAvailabilityZones",
        "ec2:DescribeLaunchTemplates",
        "ec2:CreateLaunchTemplate",
        "cloudformation:CreateStack",
        "cloudformation:DeleteStack",
        "cloudformation:DescribeStacks",
        "cloudformation:DescribeStackEvents",
        "cloudformation:ValidateTemplate",
        "ec2:AssociateIamInstanceProfile",
        "ec2:DescribeIamInstanceProfileAssociations",
        "ec2:DisassociateIamInstanceProfile",
        "iam:GetRole",
        "iam:TagRole",
        "kms:ListAliases",
        "cloudformation:ListStacks"
      ],
      "Resource": "*"
    },
    {
      "Effect": "Allow",
      "Action": [
        "ec2:TerminateInstances"
      ],
      "Condition": {
        "StringLike": {
          "ec2:ResourceTag/OCCMInstance": "*"
        }
      },
      "Resource": [
        "arn:aws:ec2:*:*:instance/*"
      ]
    }
  ]
}

  5. Select Next and add tags, if needed.

  6. Select Next and enter a name and description.

  7. Select Create policy.

  8. Either attach the policy to an IAM role that the Console can assume or to an IAM user so that you can provide the Console with access keys:

    • (Option 1) Set up an IAM role that the Console can assume:

      1. Go to the AWS IAM console in the target account.

      2. Under Access Management, select Roles > Create Role and follow the steps to create the role.

      3. Under Trusted entity type, select AWS account.

      4. Select Another AWS account and enter the ID of the Console SaaS account: 952013314444

      5. Select the policy that you created in the previous section.

      6. After you create the role, copy the Role ARN so that you can paste it in the Console when you create the Console agent.

    • (Option 2) Set up permissions for an IAM user so that you can provide the Console with access keys:

      1. From the AWS IAM console, select Users and then select the user name.

      2. Select Add permissions > Attach existing policies directly.

      3. Select the policy that you created.

      4. Select Next and then select Add permissions.

      5. Ensure that you have the access key and secret key for the IAM user.

Result

You should now have an IAM role that has the required permissions or an IAM user that has the required permissions. When you create the Console agent from the Console, you can provide information about the role or access keys.

Step 3: Create the Console agent

Create the Console agent directly from the the Console web-based console.

About this task

  • Creating the Console agent from the Console deploys an EC2 instance in AWS using a default configuration. Do not switch to a smaller EC2 instance with fewer CPUs or less RAM after creating the Console agent. Learn about the default configuration for the Console agent.

  • When the Console creates the Console agent, it creates an IAM role and an instance profile for the instance. This role includes permissions that enables the Console agent to manage AWS resources. Ensure the role is updated as new permissions are added in future releases.
    Learn more about the IAM policy for the Console agent.

Before you begin

You should have the following:

  • An AWS authentication method: either an IAM role or access keys for an IAM user with the required permissions.

  • A VPC and subnet that meets networking requirements.

  • A key pair for the EC2 instance.

  • Details about a proxy server, if a proxy is required for internet access from the Console agent.

  • Set up networking requirements.

  • Set up AWS permissions.

Steps

  1. Select Administration > Agents.

  2. On the Overview page, select Deploy agent > AWS

  3. Follow the steps in the wizard to create the Console agent:

  4. On the Introduction page provides an overview of the process

  5. On the AWS Credentials page, specify your AWS region and then choose an authentication method, which is either an IAM role that the Console can assume or an AWS access key and secret key.

    Tip If you choose Assume Role, you can create the first set of credentials from the Console agent deployment wizard. Any additional set of credentials must be created from the Credentials page. They will then be available from the wizard in a drop-down list. Learn how to add additional credentials.

  6. On the Details page, provide details about the Console agent.

    • Enter a name for the instance.

    • Add custom tags (metadata) to the instance.

    • Choose whether you want the Console to create a new role that has the required permissions, or if you want to select an existing role that you set up with the required permissions.

    • Choose whether you want to encrypt the Console agent's EBS disks. You have the option to use the default encryption key or to use a custom key.

  7. On the Network page, Specify a VPC, subnet, and key pair for the instance, choose whether to enable a public IP address, and optionally specify a proxy configuration.

    Ensure you have the correct key pair to access the Console agent virtual machine. Without a key pair, you cannot access it.

  8. On the Security Group page, choose whether to create a new security group or whether to select an existing security group that allows the required inbound and outbound rules.

    View security group rules for AWS.

  9. Review your selections to verify that your set up is correct.

    1. The Validate agent configuration check box is marked by default to have the Console validate the network connectivity requirements when you deploy. If the Console fails to deploy the agent, it provides a report to help you troubleshoot. If the deployment succeeds, no report is provided.

    If you are still using the previous endpoints used for agent upgrades, the validation fails with an error. To avoid this, unmark the check box to skip the validation check.

  10. Select Add.

    The Console prepares the instance in about 10 minutes. Stay on the page until the process completes.

Result

After the process is complete, the Console agent is available for use from the Console.

Note If the deployment fails, you can download a report and logs from the Console to help you fix the issues. Learn how to troubleshoot installation issues.

If you have Amazon S3 buckets in the same AWS account where you created the Console agent, you'll see an Amazon S3 working environment appear on the Systems page automatically. Learn how to manage S3 buckets from NetApp Console