Upon purchasing a VFNM solution, you receive an email with a VNFM install package download URL, as well as an associated product license key (ric_vnfm_serial), which you use only for obtaining support.
F5 VNF Manager requires the following system networks and components be configured and running in your virtualized infrastructure manager (VIM) or private cloud environment, as depicted in the following diagram.
Pre-existing networks and components¶
As you can see in the previous diagram, VNFM requires that your environment have the following, preexisting components and networks configured PRIOR to installing a VNFM image:
- Management network (mgmt) and subnet accessible to the Internet, which the VNFM will use to manage deployment of your cloud resources, connecting BIG-IPs to the BIG-IQ and the VNF Manager.
- Packet gateway network (pgw) and subnet is the provider network on the subscriber side of the Gi-LAN, transporting application transactions.
- Provider network and subnet is the provider network on the packet data network (Internet) side of the Gi-LAN, transporting subscriber packets to your internal, provider servers.
- Control network and subnet represents where the F5 NFV solutions connect to processes such as, your policy and control rules function engine, subscriber service-charging functions, signaling, and other similar processes.
- PGW_Dag_Net and subnet is the internal, provider network on the subscriber side. For VMware ONLY, VNFM requires that you create this network manually. For OpenStack users, VNFM creates this network automatically, during the launch process.
- PDN_Dag_Net and subnet is the internal, provider network on the packet data network (Internet) side. For VMware ONLY, VNFM requires that you create this network manually. For OpenStack users, VNFM creates this network automatically, during the launch process.
Other network setups and components not depicted in the diagram include:
- High availability network (ha_net) and subnet used for VNF layers to support master-slave, hot-standby pairs. For VMware ONLY, VNFM requires that you create this network manually. For OpenStack users, VNFM creates this network automatically, during the launch process.
- Shared storage in OpenStack used for storing virtual machines or in vSphere shared storage/datastore cluster used for virtual machines and content library that requires write-access.
In addition to networks depicted in the previous diagram, you must also download and launch the following supported F5 products in your VIM. Download the file extension type (qcow2 or OVF) required by your VIM:
|F5 VNF Manager image||Upon purchasing F5 VNF Manager, you receive an email with a link to the qcow2 or OVF file and a license key (used for acquiring support).|
|BIG-IQ 6.0.1 and F5-BIQ-VE-LIC-MGR-LIC license key||This activates the BIG-IQ License Manager utility module that manages licensing for BIG-IPs (utility pools) during orchestration. Before launching F5 VNF Manager, you must manually configure the BIG-IQ License Manager, or use the BIG-IQ blueprint to automate this process.|
|BIG-IP 18.104.22.168 Virtual-Edition and F5-BIG-MSP-LOADV12-LIC license key||Use the Utility License, automatic method (if connected to the Internet) or the manual method (if not connected).|
|CentOS-7-x86_64-GenericCloud-1503||Image used by VNFM blueprints to create the Nagios virtual machine that monitors BIG-IP VE’s.|
Set up your VIM¶
- Complete the setup for one of the following, supported VIMs:
- Open the email from F5 Networks with the link to the VNF Manager download package and license key, click the download link, and then download the image locally.
- Point your browser to the following component sites, and download the image file extension compatible with your VIM:
- BIG-IQ 6.0.1 download site, and then download the product using the F5-BIQ-VE-LIC-MGR-LIC key.
- BIG-IP 22.214.171.124 download site, and then download the Virtual-Edition product using the F5-BIG-MSP-LOADV12-LIC key (1SLOT image required for sufficient disk space). Select the applicable file extension, depending upon your VIM (OpenStack select qcow2 and VMware select OVA).
- CentOS download site, and then download the CentOS-7-x86_64-GenericCloud-1503.qcow2 package for OpenStack or the OVF package for VMware.
- Upload all images into your private, VIM project. For detailed instructions visit docs.openstack.org for v10, docs.openstack.org for v13, or VMware Docs.
- You must license and configure the BIG-IQ License Manager utility pool or use the BIG-IQ blueprint to automate this step BEFORE deploying F5 VNFM blueprint solutions.
- Deploy your F5 VNFM image.
Post-deployment system overview¶
When finished deploying your VNFM, you will have the following system:
Once you upload BIG-IQ, BIG-IP, and the VNFM images into your cloud environment (for example, OpenStack or VMware), and deploy the VNFM blueprint, then your management network will also connect the BIG-IQ license manager, the BIG-IPs deployed by the blueprint, and your F5 VNF Manager.
Client network outbound traffic flows from the packet gateway, into the disaggregation (DAG) tier where it is distributed to a service layer that is comprised of BIG-IP VE - virtual machine (VM) instances. The VEs in the service layer perform operations like, TCP optimization. As traffic throughput increases, the service layers will auto-scale or add VMs until the layer reaches the maximum throughput that you purchased. Traffic exits the service layer directly towards the external gateway, and bypasses the DAG on the way to its destination.
Return traffic flows from the external gateway into the DAG tier, where it is returned back to the VE in the service layer that originally handled the outbound traffic. This ensures that typical asymmetric traffic returned to the solution remains symmetric inside the solution. Any additional processing of network traffic is done by the VE in the service layer, and then traffic is returned directly back to the packet gateway and back to the client, again bypassing the DAG tier.
Set up an integrated CGNAT¶
This CGNAT functionality uses a set of AS3 declaration modifications and configured inputs, deployed by either a Gi LAN or Gi Firewall solution in an OpenStack environment for F5 VNF Manager version 1.3.0 and later.
To implement CGNAT capabilities, you require the following:
|Deployed F5 VNF Manager 1.3.0 prerequisites||
A deployed VNFM version 1.3.0 with all the required F5 products:
An F5-VNF-Service-Layer-Gilan or Firewall blueprint - BIG-IQ 6.0.1 (license manager with F5-BIG-MSP-LOADV12-LIC and F5-BIG-MSP-CGN-08 license keys) - BIG-IP 126.96.36.199 Virtual-Edition - CloudInit - CGNAT-enabled AS3 declaration
For a complete list of component and network requirements, see the prerequisites.
|VNFM plugins||The f5-gilan and f5-ric plugins.|
|Large scale NAT address pool||Pool of carrier-grade end sites configured with private network addresses, translated to public IPv4 addresses, using an address translator. The CGNAT-enabled Gi LAN/Firewall deployment AS3 configuration will use the address pool during scaling. You must configure your address pool with discrete IP sets, which can originate from different subnets or VLANs. VNFM will, at minimum, assign five IPs to each VNF slave instance, so be sure to provide enough IP addresses in your address list.|
Post-deployment CGNAT overview¶
When finished deploying a F5 VNFM Gi LAN/Firewall solution blueprint with a CGNAT-enable AS3 declaration, you will have the following system:
The previous diagram illustrates a limited four-list, Gi LAN+CGNAT deployed by a modified AS3 declaration for configuring CGNAT with scaling forced by Nagios, and based on CPU usage. F5 VNFM manages the address pool you defined in the inputs as lists of IP addresses. Each instance of the CGNAT VE will take the configuration from the VNFM-managed pool of addresses, use one address list, and then update the group outputs with the used address list.
Security, in the context of a VNF Manager, means securing communication with the VNF Manager and controlling who has permissions to use it to execute operations. Secured communication is achieved using SSL, which allows clients to validate the authenticity of the VNF Manager, and to ensure that the data sent to and from it is encrypted. Controlling access to VNF Manager, and permissions to perform actions, is implemented via Flask-Security, to support user authentication and authorization.
VNF Manager is secured by default. It cannot be bootstrapped in a non-secured way. For details about VNFM’s SSL and Access Control implementation and configuration, see the following:
VNFM security for client access focuses on the REST service, which this is the first and only access point of clients to VNF Manager. All requests to VNF Manager are authenticated and authorized before reaching their endpoint. For example, when a VNFM Console user attempts to upload a new blueprint, a request is sent to the REST service’s /blueprints endpoint through port 80 / 443. The request only reaches the endpoint if the user is logged in and is authorized to upload blueprints. Similarly, a user who executes the CLI command cfy deployments list triggers a request to execute GET on /deployments that is only be successful if it includes valid credentials that identify an authorized user. Requests generated by other HTTP clients (e.g. curl) must also include valid credentials. Required credentials are a user name and password, or a VNFM-generated token, and a tenant name. If credentials are missing, invalid, or represent an unauthorized user, the request fails with a “401: Unauthorized User” error.
The /version endpoint is not a secured resource, and is therefore open to all users.
Communication from the external environment to VNF Manager and its SSL/TLS configuration is the user’s responsibility (CA/host verification, etc.), where the endpoints include the UI and REST API. Communication between VNFM agents and VNF Manager (and within VNF Manager) is the responsibility of VNFM, and is determined by VNFM. VNFM generates the necessary certificates for internal communication. Credentials do not appear in log files (cloud/RabbitMQ/VNFM).
- Internal services access the REST API/file server over HTTPS on port 53333 through the manager’s private IP with a VNFM generated authentication token.
- External access to REST API/file server (e.g. CLI, UI) is done by default over HTTP through the manager’s public IP, but can be configured to use HTTPS with a customer-signed certificate. Authentication is done via a VNFM generated authentication token or with user and password.
- Agents access the manager over two secure channels: AMQP (5671) and HTTPS (53333). By default agents access the manager over its private IP, but can be configured to use other additional IPs.
SSL for internal communication
All internal communications between internal services/agents and the REST API/RabbitMQ are done over SSL.
During the bootstrap, the manager creates (or accepts as input) an internal CA certificate and key. VNFM then creates an SSL keypair with a matching certificate that contains the private IP and all the management network IPs as its CN value. The keypair is used by both RabbitMQ and REST API/file server for internal access.
As part of the agent’s installation script, VNFM’s internal CA certificate is propagated to the agent’s host in order to validate the manager’s certificate. There are no agent-host certificates.
Customizing SSL for internal communication
You can override the internal Manager certificate, and the CA certificate in the VNF Manager configuration. To provide a custom internal CA certificate for the agents to use, add the ca_certificate and optionally ca_key inputs must be set in the /opt/VNFM/config.yaml file during (installation or update of the VNF Manager. To provide a custom internal certificate, use the internal_certificate and internal_key inputs. If none are provided, VNFM will generate the CA and the internal certificate automatically.
If provided, the internal certificate must be generated with the appropriate subjectAltName extension to allow connections over every used Manager IP or hostname. The internal certificate must be signed by the CA certificate. If the ca_certificate and ca_key inputs are provided, the internal certificate will be generated and signed using the provided CA. If the ca_certificate is provided, but ca_key is NOT provided, then VNFM cannot generate the internal certificate and the internal_certificate and internal_key inputs are required. In order to use a VNF Manager cluster, the CA key must be present - either generated automatically by VNFM, or passed in the ca_key input.
SSL mode for external communication
VNF Manager, by default, doesn’t use SSL for external communication. You can set the manager to use ssl for the external communication during bootstrap or after bootstrap.
During bootstrap, you can edit the manager blueprint input. In the Security Settings section, set ssl_enabled parameter to true, in order to set the manager ssl mode.
You can set the rest_certificate and rest_key parameters, to use your own certificate. If missing, the manager will auto generate the certificate.
After bootstrap, you can use cfy ssl command to enable or disable the ssl mode. You can also change the manager certificate by replacing the files under /ssl/. The relevant files are: VNFM_external_cert.pem and VNFM_external_key.pem.
When bootstrapping with ssl mode, during the bootstrap the certificate will be copied to the local cli-profile. When using CA signed certificate, you’ll need to update it in the cli-profile (to contain the CA certificate and not the manager certificate) or to remove it (depends on the organization configuration)
In order to update the certificate in the cli-profile, you’ll need to run the following command: cfy profile set –rest-certificate CA_CERT_PATH
In case you renew the certificate, just update it in the manager, under /ssl.
Additional Security Information¶
- All services required by VNFM run under the VNFM (and not root) user in the manager VM. The only exception is the parent process of Nginx, which runs as root in order to enable use of port 80. It is not recommended to change this behavior.
- A secrets store is implemented inside the VNFM PostgreSQL database, which provides a tenant-wide variable store.
- Through usage of the secrets store, a user can ensure all secrets (such as credentials to IaaS environments, passwords, and so on) are stored securely and separately from blueprints, and adhere to isolation requirements between different tenants.
- Users need not know the actual values of a secret parameter (such as a password), since they can just point to the secrets store.
- Secrets can be added to the store using a SET function, and retrieved via GET.
- Plugins can access the secrets store, to leverage the secrets when communicating with IaaS environments.
- VNF Manager instances must be secured via SSL to ensure secrets are not passed on an unencrypted communication channel.
- Use of PostgreSQL ensures that secrets are replicated across all VNF Manager instances within a cluster, as part of HA.
Learn more about the secret store.
Security operations, such as authenticating success or failure and user details, are audited in dedicated log file on the management server. The default configuration is:
audit_log_file: /var/log/VNFM/rest-security-audit.log audit_log_level: INFO audit_log_file_size_MB: 100 audit_log_files_backup_count: 20
audit_log_file–Sets the full path to the auditing file on VNF Manager.
audit_log_level–Modifying the log level produces elaborate security auditing. Valid values are: CRITICAL, ERROR, WARNING, INFO or DEBUG.
audit_log_file_size_MB–Limits the log file size. By default, the file is limited to 100 MB. When the file reaches that size, it is renamed with the extension “.1”, and a new log file is created (older files are renamed with the extension “.2”, “.3” and so on).
audit_log_files_backup_count–Sets the maximum number of old log files to keep. By default, this value is 20, meaning that up to 20 log files can be created, after which the oldest file is removed.