To deploy F5 VNFM, do the following:
- Download VNFM image
- Launch an instance in OpenStack
- Add a floating IP in OpenStack
- Secure access to your F5 VNFM
- Manage secrets
- Define parameters in the inputs.yaml file
- Deploy local F5 Gilan blueprint
Consult the supporting reference topics, following these steps.
Step 1: Download VNFM image¶
Download all three components to your management system:
- Open the email from F5 Networks providing you the link to the VNF Manager download package and license key, click the download link, and download the image locally.
- Point your browser to the BIG-IQ 6.0.1 download site, and download the product using the F5-BIQ-VE-LIC-MGR-LIC key. At a minimum, you must license the BIG-IQ License Manager.
- Point your browser to the BIG-IP 13.1.1 download site, and download the Virtual-Edition product using the F5-BIG-MSP-LOADV12-LIC key.
- Upload all three images into your OpenStack-Newton project. For detailed instructions, see Upload and manage images on docs.openstack.org.
Step 2: Launch an instance in OpenStack¶
PREREQUISITE: The following table lists the VNFM-required administrative OpenStack environment components and guidelines that must exist PRIOR to creating a VNFM instance in your OpenStack project.
- Once the following components exist in your environment, create and name a VNFM instance, and then define the following parameters, clicking Next to complete the wizard. (Click the following links to learn more about using the Newton version of OpenStack.)
|Source||Expand Select Boot Source, and choose Image, under Create New Volume, click No, and then click + next to the latest VNFM image file to move it to the Allocated list.|
Select a flavor sized accordingly, to accommodate the VNFM component images you previously uploaded. The minimum flavor requirements for deploying the F5 VNF Manager include:
Select + next to the following predefined network (and subnet), to add to the Allocated list:
Select + next to the following, predefined security group to add to the Allocated list:
|Key Pair||Create, import, or select existing key pair for accessing VNFM instance remotely, using SSH.|
- For all other Instance component definitions, use the default values provided by OpenStack, and then click Launch Instance. For details, see Upload and manage instances on the docs.openstack.org.
Step 3: Add a floating IP¶
Once you launch your instance in OpenStack, expand the Create Snapshot drop-down next to your instance in the table, and select Associate a Floating IP from the list. Choose an IP address from the list. If none, click + to add one. This allocates the floating IP on the management network. Do this to access the VNFM externally from a browser, using https.
Step 4: Secure access to your F5 VNFM¶
- To access your VNFM, point your browser to the public IP address you created in the previous steps, using https.
- Login using username: admin and password: admin.
- To change your username and password, on the left-side menu, click the Tenant Management blade, and set a complex admin password. Learn more about User Management and Tenant Management.
IMPORTANT: F5 recommends managing your VNFM administration account using a role-based access control (RBAC) method, such as LDAP or Active Directory. Learn more about integrating with LDAP. At a minimum, set a complex admin password.
Step 5: Manage secrets¶
In F5 VNFM, click, click next to each of the following secrets to edit the values for your project. Doing so enables your blueprint to access these values as needed, during orchestration, without exposing the plain text values.
IMPORTANT: To avoid deployment issues, verify that you enter these secrets correctly. For example, remove any extra spaces in the keystone secrets.
|bigip_admin_password||Set to the desired password for the default BIG-IP admin account. Default value is admin.|
|bigip_root_password||Set to the desired password for the default BIG-IP root account. Default value is default.|
|bigip_username||Default value is admin.|
|big_ip_root_user||Root user name of the BIG-IP. You must add this bigip_root_user secret to your manager.|
|agent_key_private||The private SSH key for connecting to BIG-IP instances. Browse to the local copy of the private key using the Get secret value from file option.|
|bigiq_password||Set to the password for the BIG-IQ system used for licensing BIG-IP VEs in the deployment. Default value is admin.|
|bigiq_username||Set to the user name for the BIG-IQ system used for licensing BIG-IP VEs in the deployment. Default value is admin.|
|cm_cert||Located in /<insert your path>/ssl/<your>_external_cert.pem (for more details, see Manage secure communication certificates).|
|cm_host||Set to the internal IP address of hostname of the VNF Manager. Default value is 192.168.1.0.|
|cm_password||Set to the password for the VNF Manager. Default value is admin.|
|cm_port||Set to the TCP port for connecting to the VNF Manager. Default value is 443.|
|cm_protocol||Set to the protocol for connecting to the VNF Manager. Default value is https.|
|cm_tenant||Set to the VNF Manager tenant name. Default value is default_tenant.|
|cm_trust_all||Set to true or false to determine verification of server certificates.|
|cm_user||Set to the user name of the VNF Manager. Default value is admin.|
|keystone_password||Set to the password for the account with access to the OpenStack tenant where you will deploy blueprint resources.|
|keystone_tenant_name||Set to the OpenStack tenant/project name where you will deploy blueprint resources.|
|keystone_url||Set to the v2 authentication URL of the OpenStack environment where you will deploy blueprint resources; for example,
|keystone_username||Set to the user name of the account with access to the OpenStack tenant where you will deploy blueprint resources.|
IMPORTANT: If you are allowing VNFM to create keystone resources, then you must configure the keystone account with the required OpenStack permissions. Learn more at docs.openstack.org.
|nagiosrest_pass||Set to the desired password for the Nagios monitoring instance. Default value is testuser.|
|nagiosrest_user||Set to the desired user name for the Nagios monitoring instance. Default value is testpass.|
|Region||Set to the OpenStack region where you will deploy blueprint resources. Default value is nova.|
For more information, see using the secret store.
Step 6: Define parameters in the inputs.yaml file¶
The F5 blueprint uses an inputs.yaml file that you must edit, adding your system definitions:
- Depending on your solution, open one of the following files:
- Copy and paste the contents of the sample inputs yaml file into a new file and change the parameter values according to your application and network requirements. See the following tables for parameter descriptions to help you define your inputs.YAML file.
- Save the .yaml file locally. You will upload this file into VNFM in Step 7, deploy local F5 DeployBlueprint.
F5 blueprint inputs¶
Gilan inputs (for F5 VNFM Gi LAN and Gi Firewall solutions and VNFM base)
|pgw_dag_subnet_mask||Yes||The network mask of the pgw_dag subnet.|
|default_gateway||Yes||The next hop IP address for outbound traffic egressing the VNF.|
VNF Resource Information Collector inputs (for Gi LAN and Gi Firewall solutions ONLY)
|ric_throughput||Yes||Desired throughput for the VNF layer, in Gbps (options include: 5, 10, 50 Gbps).|
|ric_purchasing_model||Yes||The purchasing model for licensing (options include: subscription or perpetual).|
|ric_licensing||Yes||The solution you are deploying (options include: gilan or firewall)|
|ric_vnfm_serial||Yes||The VNFM license key provided in your email from F5 (used for support purposes only).|
|auto_last_hop||Yes||Controls how the DAG receives return traffic from the internet. Enable this input, if you are using an F5 device to NAT outbound connections; otherwise, disable.|
Network inputs (for F5 VNFM Gi LAN and Gi Firewall solutions and VNFM base)
|bgp_dag_pgw_peer_ip||Yes||The IPv4 address of the DAG BGP peer on the provider gateway (for example, 192.168.1.1).|
|bgp_vnf_pgw_peer_ip||Yes||The IPv4 address of the VNF BGP peer on the provider gateway (for example, 192.168.2.1).|
|bgp_pgw_peer_as||Yes||The BGP autonomous system number of the provider gateway (for example, 200).|
|bgp_dag_egw_peer_ip||Yes||The IPv4 address of the DAG BGP peer on the external gateway (for example, 192.168.3.1).|
|bgp_egw_peer_as||Yes||The BGP autonomous system number of the external gateway. (for example, 300).|
VNF inputs (for F5 VNFM Gi LAN and Gi Firewall solutions and VNFM base)
|ctrl_net||Yes||The name of the control network.|
|ctrl_subnet||Yes||The name of the control network subnet.|
|ha_net||Yes||The name of the high availability network (for config. sync and network failover purposes).|
|ha_subnet||Yes||Name of the high availability network subnet.|
Monitoring inputs (for F5 Gi LAN and Gi Firewall solutions ONLY)
|floating_network_id||Yes||The OpenStack ID or name of the network where you assigned a floating IP addresses.|
|centos_image_id||Yes||The OpenStack ID of the CentOS image to use when creating the monitoring nodes.|
|nagios_flavor_id||Yes||The OpenStack ID of the flavor to use when creating the monitoring nodes.|
Common inputs (for F5 VNFM Gi LAN and Gi Firewall solutions and VNFM base)
|cm_ip||Yes||The internal IP address of the VNF Manager instance.|
|sw_ref_dag||Yes||A dictionary that defines the OpenStack image and flavor to use for the BIG-IP VE disaggregation instances.|
|sw_ref_vnf||Yes||A dictionary that defines the OpenStack image and flavor to use for the BIG-IP VE virtual network functions instances.|
|bigip_os_ssh_key||Yes||The name of the OpenStack SSH key that you will import into the BIG-IP VE instances.|
|big_iq_host||Yes||The IP address of the BIG-IQ VE instance that will assign licenses to the BIG-IP VE instances.|
|big_iq_lic_pool||Yes||The name of the BIG-IQ key or pool that will be used to assign licenses to the BIG-IP VE instances.|
|ctrl_sg_name||Yes||The name of the pre-existing control security group.|
|max_scale_dag_group||Yes||The maximum number of layers to which the DAG group will scale.|
|max_heal_vnfd_dag_ve||Yes||Maximum number of times a DAG VE will heal before it stops trying and shows an error.|
|max_heal_vnf_layer||Yes||Maximum number of times a layer will heal before it stops trying and returns an error.|
|max_heal_vnf_slave_ve||Yes||Maximum number of times a slave VE will heal before it stops trying and returns an error.|
|agent_user||Yes||The user for the client agents.|
|vnf_layer_cpu_threshold||Yes||Maximum number of times a slave VE will heal before it stops trying and returns an error.|
|vnf_layer_cpu_threshold_check_interval||Yes||Interval between checks, in minutes.|
|vnf_group_throughput||Yes||The desired aggregate throughput (Gigabits In Out) for every layer in the group. Example values: 5 for 5 gig, 10 for 10 gig, 0.5 for 500mb.|
|vnf_group_throughput_threshold||Yes||New layer is added to group when the percentage of average aggregate layer throughput exceeds this value (for example, 75).|
|vnf_group_throughput_check_interval||Yes||Interval between checks, in minutes.|
|dag_group_cpu_threshold||Yes||New instance is added to group when the percentage of average aggregate Global TMM CPU usage of all DAG group instances exceeds this value (for example, 75).|
|dag_group_cpu_threshold_check_interval||Yes||Interval between checks, in minutes.|
|mgmt_sg_name||Yes||The name of the pre-existing management security group.|
|pgw_sg_name||Yes||The name of the pre-existing packet gateway (PGW) security group.|
|pdn_sg_name||Yes||The name of the pre-existing provider data network (PDN) security group.|
|snmp_sg_name||Yes||The name of the pre-existing SNMP security group.|
|mgmt_net||Yes||The name of the pre-existing management network.|
|mgmt_subnet||Yes||The name of the pre-existing management network subnet.|
|pgw_net||Yes||The name of the pre-existing PGW network.|
|pgw_subnet||Yes||The name of the pre-existing PGW subnetwork.|
|pdn_net||Yes||The name of the pre-existing PDN network.|
|pdn_subnet||Yes||The name of the pre-existing PDN network subnet.|
|pgw_dag_net||Yes||The name of the pre-existing PGW-DAG (VNF ingress) network.|
|pgw_dag_subnet||Yes||The name of the pre-existing PGW-DAG network subnet.|
|pgw_dag_subnet_cidr||Yes||The CIDR of the pre-existing PGW-DAG network subnet (for example, 192.168.1.0/24).|
|pdn_dag_net||Yes||The name of the pre-existing PDN-DAG (VNF egress) network.|
|pdn_dag_subnet||Yes||The name of the pre-existing PDN-DAG network subnet.|
|pdn_dag_subnet_cidr||Yes||The CIDR of the pre-existing PDN-DAG network subnet (for example, 192.168.2.0/24).|
AS3 Declaration (for F5 VNFM Gi LAN and Gi Firewall solutions ONLY)
|vnf_as3_nsd_payload||Yes||The F5 AS3 declaration, in YAML format, that defines the service configuration of the VNF instances. IMPORTANT: You will edit this declaration as appropriate for your solution; however, the VLAN names used in the allowVlans property for each service MUST correspond to the values of the pgw_dag_net (for outbound traffic) a pdn_dag_net inputs (for inbound traffic).|
Step 7: Deploy local F5 blueprint¶
Once you change all the values in the Gi LAN or Base inputs file and save it locally, upload the file into F5 VNF Manager. The inputs file will define all required parameters for the following blueprint files depending on the solution you selected:
- Open F5 VNFM, click Local Blueprints. One of the following blueprint files appear, depending on the solution you selected:
- F5-VNF-Service-Layer-GiLAN.yaml main blueprint file
- F5-VNF-Service-Layer-Firewall.yaml main blueprint file
- F5-VNF-Service-Layer-Base.yaml main blueprint file
- Click Deploy.
- Enter a name, under Deployment Inputs, click browse for the
inputs_[solution name].yamlfile you edited, and then click Open. The Deploy blueprint form is completed automatically with the values you entered in the
- Click Deploy, on the left-side menu click the Deployments blade, in the list next to blueprint you created in the previous step, expand , click Install, and then click Execute. VNFM starts creating BIG-IP VEs according to the parameters you defined for your network. Also installed includes additional, sub-blueprints packaged with the F5 gilan blueprint.
- Once your blueprint install finishes executing, to view a model of your VNF installation, on the Deployments blade, click a name from the list. A model of your VNF topology appears, along with a list of all the nodes, and event logs.
To add an events and logs filtering widget to this page
- In the top-right corner click your login name, select Edit Mode, and then click Add Widget.
- Scroll the list and select Events/logs filter, and then click Add selected widget.
- Scroll to the top of the page, click and drag the Events/logs filter widget down the page, and place it just before the Deployment Events/Logs pane on the page.
- Close the Edit mode dialog box. You can now filter event/logs based on type, log level, and other similar criteria. Learn more about events and logs.
- To view the list of Gilan workflows (for example, scale out group, heal VE, etc.) that you can run, on the Deployments blade, click next to your Gilan deployment in the list. A list of applicable workflows for your solution appears. Learn more about workflows and which workflows to run for which deployments.
- To view the multiple BIP-IP VEs created by installing your F5 Gilan blueprint, open your OpenStack project and navigate to .
Supporting deployment reference topics¶
Consult the following topics, which provide further discussion and how-to information for performing the previous deployment steps.
Displays the list of users and enables their management. This widget is only available to admin users.
The widget displays the following information regarding each of the user groups:
- Last login timestamp
- Admin - whether or not the user is sys admin on the VNF Manager (you can check and uncheck this filed to make changes)
- Active - whether or not the user is active (you can check and uncheck this field to make changes)
- # Groups - number of groups the user is a member of
- # Tenants - number of tenants the user is assigned with
The on the right of every tenant allows performing the following operations:
- Setting the user’s password
- Adding/removing the user to/from user groups
- Assigning/Unassigning the user with/from the tenant
- Deleting the user - possible only if the user does not belong to any groups, assigned to any tenants and is the creator of any resources on the manager.
Also, using Add on the top-right corner of the widget, you will be able to create new users. Please notice that if you choose to authenticate the users in front of an external user management system, you will not be able to create or delete the users in VNF Manager, nor to assigned them to VNF Manager user groups, to prevent conflicts between the two systems which can cause security problems.
Refresh time interval- The time interval in which the widget’s data will be refreshed, in seconds. Default: 30 seconds.
Displays a list of tenants on the Manager and enables tenant management. This widget is only available to admin users. The widget displays the following information regarding each of the tenants:
- Number of user-groups assigned to the tenant
- Number of users directly assigned to the tenant (not as part of groups)
The on the right of every tenant allows performing the following operations:
- Adding/removing users to/from the tenant
- Adding/removing user-groups to/from the tenant
- Deleting the tenant - possible only if the tenant has no users. User-groups or resources associated with it.
Also, clicking Add on the top-right corner of the widget, you can create new tenants.
Refresh time interval- The time interval in which the widget’s data will be refreshed, in seconds. Default: 30 seconds.
vnfm ldap command is used to set LDAP authentication to enable you to integrate your LDAP users and groups with F5 VNFM.
Note: You can use the CLI vnfm declaration in the F5 VNF Manager ONLY.
These will work on each command:
-v, --verbose- Show verbose output. You can supply this up to three times (for example, -vvv)
-h, --help- Show this message and exit.
vnfm LDAP set [OPTIONS]
Set F5 VNF Manager to use the LDAP authenticator.
-s, --ldap-server TEXT- The LDAP address against which to authenticate, for example: ldaps://ldap.domain.com.
-u, --ldap-username TEXT- The LDAP admin username to be set on the F5 VNF Manager.
-p, --ldap-password TEXT- The LDAP admin password to be set on the F5 VNF Manager.
-d, --ldap-domain TEXT- The LDAP domain to be used by the server.
-a, --ldap-is-active-directory- Specify whether the LDAP used for authentication is Active-Directory.
-e, --ldap-dn-extra TEXT- Additional LDAP DN options.
$ vnfm ldap set -s [LDAP SERVER ADDRESS] -u [LDAP ADMIN USERNAME] -p [LDAP ADMIN PASSWORD] -d [DOMAIN NAME]
Integrate with LDAP¶
VNFM provides a user management mechanism, so you can define different users with different permissions, and upon login perform authentication and authorization to control the users’ access to resources.
The users can be either defined and managed in F5 VNFM itself, or you can configure your Manager to integrate with an LDAP-based user-management system. You must select one of these options, as you cannot do both, and you must configure your manager accordingly upon installation or immediately afterwards, when no actions were performed on it yet.
User Management Credentials Tip: You must have F5 VNFM administrator permissions to perform user-management related actions.
Manage users by integrating with an LDAP system¶
If you choose to integrate with an external user-management system, make sure your manager is configured accordingly:
First, you must know the URL of the LDAP service and have sufficient credentials to an LDAP user with search permissions.
You then configure F5 VNFM with the LDAP configuration during the
installation process, in the
ldap section of the config.yaml file.
You can also use the API to configure an LDAP connection after F5 VNFM
Manager is installed, using the
vnfm ldap set command, as long as the
Manager is clean, meaning that no tenants, groups, users or resources
exist in it.
vnfm ldap set [OPTIONS]
-s, --ldap-server TEXT- The LDAP server address to authenticate against [required]
-u, --ldap-username TEXT- The LDAP admin username to be set on the F5 VNF manager [required]
-p, --ldap-password TEXT- The LDAP admin password to be set on the F5 VNF manager [required]
-d, --ldap-domain TEXT- The LDAP domain to be used by the server [required]
-a, --ldap-is-active-directory- Specify whether the LDAP used for authentication is Active-Directory
-e, --ldap-dn-extra TEXT- Extra LDAP DN options
-h, --help- Show this message and exit
Note: You can use the CLI vnfm declaration in the F5 VNF Manager ONLY.
vnfm ldap set -a -s ldap://<LDAP SERVER IP>:389 -u <LDAP ADMIN USER> -p <LDAP ADMIN USER PASSWORD> -d <DOMAIN.com>
How F5 VNF Manager works with the LDAP service¶
When integrating with an LDAP system, F5 VNFM will prevent you to manage users from the Manager, to prevent conflicts between the two systems which can cause security problems. Instead, users will log into F5 VNFM with their LDAP credentials, and the Manager will authenticate them against the LDAP service. To finish the authorization process into F5 VNFM, the users will have to belong (directly, or via nested groups) to an LDAP group connected to one or more F5 VNFM Tenants.
Connect F5 VNFM user-groups with the LDAP groups¶
To create this connection between the LDAP system and F5 VNFM you must create user-groups in F5 VNFM that represent your LDAP user groups. You then assign those F5 VNFM groups to tenants in F5 VNF Manager, with the desired roles. When a user logs into F5 VNFM, a request is sent to the LDAP system for authentication and identification of the groups to which the user belongs (including groups that contains groups that eventually contains the user - aka nested groups). F5 VNFM then identifies the tenants that the F5 VNFM groups (that represent the LDAP groups) can access, and allows user access according to the permissions the roles of the groups provide. For more information on creating a user group, see either the CLI command, or the Tenant Management.
In case a user belongs to multiple groups which are assigned to the same tenant with different roles, the user’s permissions in the tenant will be a sum of all the permission it receives from the different groups. For example, let’s say user-A is a member of two Groups in LDAP – “team_leaders,” and “devs.” The team_leaders group is associated in F5 VNFM with the group “all_tenants_viewers”, which is assigned to all of the manager’s tenants with the role “Viewer.” The “devs” group is associated in F5 VNFM with the group “dev_users,” which is assigned to dev_tenant with the role “User.” So, user-A is now assigned to dev_tenant twice – once as a Viewer and once as a User. Upon logging into this tenant, the permissions user-A will have will be a sum of the permissions of the two roles. After users have logged in to F5 VNFM, they are visible in the users list, but you cannot perform any management actions on their profiles.
Tip: LDAP passwords are not saved in VNF Manager.
Roles management with Ldap¶
Upon assigning a user or a user-group to a tenant, we must specify their permissions in this tenant. This is being done by adding a User Role. In user creation, we define whether the users are admins or not. If admins, they will automatically have maximal permissions to all tenants. If not, they will be marked as “default” users, meaning they exist in the system but need to be explicitly assigned to specific tenants with specific roles.
When using LDAP, we don’t manage the users, but the user-groups, so we will manage the roles through them.
When a user-group is added to a tenant, a specific tenant role must be assigned to it. By adding a user to a specific user-group, that user will inherit that user-group tenant-association along with its tenant-role (and the same for all the groups that recursively contain this group).
Add users manually¶
If you choose not to integrate F5 VNF Manager with LDAP systems, you must add each user individually and set a password for them. You can also create user-groups and add users to them. The users and user groups can be assigned to one or more tenants.
Use the Secret Store¶
The secrets store provides a secured variable storage (key-value pairs) for data that you do not want to expose in plain text in F5 VNFM blueprints, such as login credentials for a platform. The values of the secrets are encrypted in the database. We use the Fernet encryption of cryptography library, which is a symmetric encryption method that makes sure that the message encrypted cannot be manipulated/read without the key. When you create a secret, the key value can be a text string or it can be a file that contains the key value. The secret store lets you make sure all secrets (for example credentials to IaaS environments) are stored separately from blueprints, and that the secrets adhere to isolation requirements between different tenants. You can include the secret key in your blueprints and not include the actual values in the blueprints.
Update a secret with a shown value¶
- Updating the secret’s value and visibility or deleting the secret is allowed according to the user roles and the visibility of the secret.
- Updating the secret to hide the value is only allowed to the user who created it, tenant managers and sys-admins.
Create a secret from the CLI¶
You can use the
vnfm secrets command to manage VNFM secrets (key-value pairs) in the F5 VNF Manager ONLY.
$ vnfm secrets create test -s test_value … Secret ``test`` created …
For more commands, see Secrets commands.
Create a secret from the F5 VNFM Console¶
Secret Store Management is performed from the System Resources page in the VNFM Console.
Click Create in the Secret Store Management widget.
Insert the following values:
- The secret key
- The secret value (or select the secret file from your file repository)
- The visibility level (the icon of the green man)
- If the value of the secret should be hidden
Press on the eye icon for viewing the secret value.
To change the visibility level of the secret, click on the visibility icon in the key cell.
To hide the secret value, select the Hidden checkbox.
For updating the secret value there is an edit icon in the right and next to it the delete icon.
Manage secure communication certificates¶
Use the following information to securely manage communication and remote access authorization.
Customize SSL for internal communication¶
You can override the internal Manager certificate, and the CA
certificate in the F5 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 located in the /opt/cloudify/config.yaml file.
To provide a custom internal certificate, use the
internal_key inputs. If none
are provided, F5 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_keyinputs are provided, the internal certificate will be generated and signed using the provided CA. If the
ca_certificateis provided, but
ca_keyis NOT provided, then F5 VNFM cannot generate the internal certificate and the
internal_keyinputs are required.
- In order to use a F5 VNF Manager cluster, the CA key must be present - either generated automatically by F5 VNFM, or passed in the
SSL mode for external communication¶
F5 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
/home/centos/files/ssl/. The relevant files are:
cloudify_external_cert.pem and cloudify_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 /home/centos/files/ssl.
Additional Security Information¶
- All services required by F5 VNF Manager 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 F5 VNF Manager 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
SETfunction, and retrieved via
- Plugins can access the secrets store, to leverage the secrets when communicating with IaaS environments.
- F5 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 F5 VNF Manager instances within a cluster, as part of HA.
Events and logs¶
Displays the logs and events of all the executions in the current tenant, according to the user’s permissions. You can configure the fields that are displayed and can choose to indicate in colors success and failure messages.
Refresh time interval- The time interval in which the widget’s data will be refreshed, in seconds. Default: 2 seconds
List of fields to show in the tableYou can choose which fields to present. By default, these are the fields presented:
- Node Name
- Node Id
You can also choose to add the field “Type,” which will present the log
level in case of a log, and event type in case of an event. *
Color message based on type - when marked as “on,” successful events
will be colored blue, and failures in red. Default: On *
Maximum message length before truncation- Allow to define the length
of the messages presented in the table. Default: 200.
NOTE: Even if the message is being truncated in the table itself, you can see the full message upon overring.