Available Google Resources

Google Authentication Methods

1. Service Accounts—Service Accounts apply to applications or VMs—not to end users. They are commonly used to control access when you use programs or scripts, or when you access the firewall from the gcloud command line. If you are using Google Service Accounts to authenticate instances or applications, you must know the email address for the account(s). Refer to Creating and Managing Service Account Keys.
   Using a service account is necessary if you want to connect to the VM-Series firewall from outside the project—either from a different project or from the command line. For example, if you want to enable a physical next generation firewall to monitor your VM-Series firewall, you must save the VM-Series firewall service account information to a JSON file. In the physical firewall, you upload the file when you configure the connection.
   1. Select IAM & AdminService accounts and choose +Create Service Account.
      Enter the service account name and description, and click Create.
   2. Select a role type from the drop menu, and on the right, select an appropriate access level.
      For example, select Project > Editor. You can select multiple roles for a service account. When you are finished, click Continue.
   3. Grant specific users permission to access this service account. Select members from the Permissions column on the right to give them permission to access the roles in the previous step.
2. SSH Keys—If you deploy the VM-Series firewall from the Marketplace, you must supply one Open SSH key in RSA format for the Google Compute Engine instance metadata.
   The VM-Series firewall only accepts one key at deployment.
   At deployment time, you paste the public key into the Marketplace deployment, as described in SSH Key Pair. After deployment you use the private key to SSH in to the firewall to configure the administrator account. To add users, see Manage Firewall Administrators.

• Create service accounts for instances—You can create a service account for a specific instance or instance group, and grant specific permissions, which in turn can be granted to users.
• Use the default service account for your project—If you are using the Google Cloud Platform (GCP™) Console, then you logged in with your email address and can access a GCE instance based on whatever permissions or roles the project administrator assigned to your account.
  Every Google Compute Engine instance created with the Google Cloud Console or the gcloud command line tool has a default service account with the name in email address format:
  <project-number>-compute@developer.gserviceaccount.com
  To see the service account name for the firewall instance, view the instance details and scroll to the bottom (refer to the Compute Engine default service account).
  The default service account can manage authentication to VMs in the same project as a VM-Series firewall. Access scopes allow the firewall to initiate API calls to VMs in the Google Cloud project.
• Use IAM permissions and the Google APIs—If you use the Google SDK APIs and gcloud, then you must call the APIs to authenticate.
  • You typically use the Google SDK when you want to manage the firewall from a command line or you want to run a script to configure the firewall.
  • You need to access the Google APIs if a virtual machine you connect to has a custom image with applications that require Google APIs.

Virtual Private Cloud (VPC) Network Planning

• VPC networks—You must create a custom network specifically for each VM-Series firewall network interface.
  • See VM-Series Firewall Licenses for Public Clouds to determine the number of network interfaces needed based on your VM-Series firewall license. At a minimum, set up the three VPC networks and subnets required to launch the VM-Series firewall.
  • A GCP project has a default network with preset configurations and firewall rules; you can delete the default network, if unused.
  • By default, there are up to five networks in a project. Your GCP administrator can request additional networks for your project.
  • To connect to the management interface you must create a GCP firewall rules that allows access. You can do this during the deployment if you choose Enable GCP Firewall rule for connections to Management interface then supply a CIDR block for Source IP in GCP Firewall rule for connections to Management Interface.
  Be sure your networks include all instances you want to secure.
• Subnetworks—A compute engine instance can support up to eight Layer 3 interfaces on a single instance. The Management, Trust, and Untrust interfaces consume three interfaces and you can create up to five additional dataplane interfaces. Typically the dataplane interfaces represent application networks.
• IP address—You supply IP address ranges when you create interface subnetworks, and you have the option to enable an external address when you deploy a subnetwork.
  • When you create a network subnet, you must specify an IP address range. This range is used for your internal network, so it cannot overlap with other subnets.
  • During deployment, you can choose to enable an external IP address when you create a network interface. By default, you are given an ephemeral IP address. You cannot supply a reserved static IP address during the deployment, but you can promote the ephemeral address to a static IP address after you complete the deployment process (see Promoting an ephemeral external IP address).

Network Interface Planning

• Interface Order—When you deploy with Marketplace, the order of the network interfaces is predefined. The Management interface maps to eth0, Untrust to eth1, and Trust to eth2. Marketplace uses this order because mapping the Management interface to eth0 and the Untrusted interface to eth1 is a requirement if you need to Swap the Management Interface for load balancing.
• Management Interface—The first network interface you add is mapped to eth0 on the firewall and includes the option to enable IP forwarding. You use this network interface to manage the VM-Series firewall. Typically, this interface has an external IP address.
  An external IP address is only required if a dataplane interface is attached to the public subnet. At creation time, you can receive an ephemeral IP address and later promote it to a static IP address after you complete the deployment (refer to Promoting an ephemeral external IP address).
• Dataplane Interfaces (Untrust, Trust)—When you deploy from Marketplace, the order in which you add interfaces is predetermined.
  • You configure the Untrust interface after the Management interface. This order means that the untrusted interface is mapped to eth1. The Untrust interfaces are typically attached to the public subnet, and have an external IP address.
    An external IP address is only required if a dataplane interface is attached to the public subnet. At creation time, you can receive an ephemeral IP address, then promote it to a static IP address, as discussed in Promoting an ephemeral external IP address.
  • The Trust interface follows the Untrust interface, and it is mapped to eth2. The Trust network often does not have an external IP address. You can add any additional dataplane interfaces after the Trust interface.
• Additional Dataplane Interfaces—Plan interfaces for applications you must secure, such as web servers, databases, and other applications in your network. You can create up to five additional dataplane interfaces in addition to the three required to launch your firewall. Ensure that the applications you want to secure are in networks that connect to the VM-Series firewall.