Understanding iApps
Understanding iApps iApps are powerful tools. Used by roughly one third of all F5 customers, they perform input validation and apply complex business logic for configuring a wide variety of applications. They hide complexity, sometimes driving hundreds of configuration parameters with just a handful of input values. They also provide deployment guidance, reducing the need for documentation and training. But iApps are often misunderstood and misused, sometimes with frustrating consequences. iApp, not Wizard It is helpful to understand the difference between an iApp and a wizard. A wizard is usually a script with a GUI. It is a tool that accepts a set of user inputs and performs a one-time procedure. When run twice, a wizard performs exactly the same steps during its second run as it did during its first. Although an iApp is also a script with a GUI, it behaves differently on re-entry. Unlike a wizard, an iApp maintains a relationship to the configuration that it generates. iApps have 5 critical properties: iApps always act atomically. The result of deployment is always either the entire intended configuration or none at all. iApp-driven configuration objects are marked so the iApp can track them throughout its lifecycle. A visualization of these configuration objects is presented in the popular TMUI “Component View.” iApps protect the configuration from accidental changes. iApp-driven elements may not be changed via the UI or CLI except through the iApp. iApps support re-entry. Since the iApp framework tracks the configuration objects that it manages, it can be intelligent about which elements are touched during reconfiguration. iApps automatically perform cleanup on deletion. The housekeeping is automatic, and the iApp author does not need to (and is not allowed to) write any delete-time code. Mark and Sweep On initial deployment, an iApp builds a configuration as directed by the TMSH commands in the iApp’s implementation section. On reconfiguration, the iApp framework again runs the implementation, but does not immediately submit the result to BIG-IP. Instead, it first compares the desired (new) configuration with the existing (old) configuration. All similarities are dropped from the workload. If existing elements are missing from the desired configuration, the framework automatically prepares delete requests for those elements. In the end, the changes submitted to BIG-IP are the minimum necessary to accomplish the desired configuration. TMSH “create” commands used to build config on the initial deployment are automatically changed to “modify” on re-entry. This mechanism, known as “mark-and-sweep,” reduces a scripted change set to its net effect, often allowing iApps to reconfigure BIG-IP with no disruption to data plane traffic. Strict Updates As noted above, an iApp tags all of the configuration objects under its control and BIG-IP prevents users from modifying these objects outside the iApp. This restriction, called “strict-updates”, can be disabled. The negative consequences of this action are often underestimated. To illustrate the typical frustration, consider a simple iApp that accepts 2 inputs and constructs a virtual server with a custom HTTP profile: presentation { section virtual { string ip required choice xff { “enabled”, “disabled” } } } implementation { tmsh::create ltm profile http ${tmsh::app_name}_http \ insert-xforwarded-for $::virtual__xff tmsh::create ltm virtual ${tmsh::app_name}_vs \ destination $::virtual__ip:80 \ profiles add \{ ${tmsh::app_name}_http \} } Suppose you deploy this iApp with X-Forwarded-For enabled, then disable strict-updates and edit the HTTP profile directly as shown: Now, re-enter and re-deploy the iApp without changing any inputs. What is the result? You might expect your manual customization of response chunking to remain in place, because there is no mention of response chunking in the iApp code. In this case, however, iApp re-deployment causes chunking to be set back to its default value. Consider another change, this time to the virtual server: Disable address translation, then re-enter and re-deploy the iApp again. What is the result this time? You might expect your customization to be overwritten as it was in the previous example. In this case, however, address translation remains disabled. The TMSH “modify” command does not handle defaults consistently across all key-value pairs. This makes tampering with an iApp-enforced configuration especially hazardous. Right Use Hopefully, this article provides some insights that will help you use iApps to your best advantage. An iApp is a scripted management tool that is dedicated to an application for life. If you find yourself wishing to disengage the iApp and tamper with its configuration, instead consider modifying the iApp code to accomplish your goals. If you absolutely must disable strict-updates, do so with crystal-clear expectations for managing that application going forward.
Creating, Importing and Assigning a CA Certificate Bundle
Within this article, I will be using a personal and relative use case to my own customers. While many organizations may only have one or two Root CA's to identify, the US Department of Defense has numerous CA's sometimes making it difficult for new F5 admins to grasp the concept of a certificate bundle and where to use it. In this article I wanted to take just a few minutes to walk you through the creation of a CA bundle, importing it into the BIG-IP and where you would apply the bundle to perform functions such as smart card authentication. If you would like to attempt to use the cert bundle iApp created by F5, the iApp deployment guide can be found using the link below though deploying that iApp is outside the scope of this document. With all of that, let's begin. https://f5.com/solutions/deployment-guides/ca-bundle-iapp-big-ip-v115-v12 Obtaining all CA's to Include in the Bundle For DoD customers, navigate to https://iase.disa.mil/pki-pke/Pages/index.aspx Select For Administrators, Integrators and Developers Select Tools and continue to browse until you locate PKI CA Certificate Bundles: PKCS#7 Select and download the certificate bundle that is appropriate for your organization though as an example I have selected For DoD PKI Only. Locate the Zip file in the directory you downloaded it to, right click and select extract. Copy Required Files to the BIG-IP After you have extracted all of the files within the .zip file, using your preferred SCP application, copy the file name with the extension of .pem.p7b as shown in this example Certificates_PKCS7_v5.3_DoD.pem.p7b. Note: For Windows users PowerShell can be used to SCP files though if you prefer WinSCP it is certainly acceptable. Run the command scp -p @: Convert the PKCS Certificate to PEM format SSH to the BIG-IP Navigate to the directory you placed the .p7b file during the SCP process above. Run the command openssl pkcs7 -in .p7b -text -out .pem -print_certs to convert the file from the p7b file format to pem. Once you have converted the file from p7b to pem format run the command tmsh install sys crypto cert from-local-file to import the file into the BIG-IP certificate store. To save the config, run the command save sys config Validate Cert Bundle was Imported Log into the BIG-IP TMUI >> System >> Certificate Management >> Traffic Certificate Management >> SSL Certificate List Locate the certificate name that you used in the previous step to import the pem file into the certificate store. To view the certificates included in that bundle, click the certificate bundle and within the certificate tab you can view all certificates. Assign the CA Bundle to a SSL Client Profile This task is most commonly used in SSL client profiles assigned to applications performing smart card or user certificate based authentication. Navigate to Local Traffic >> Profiles >> SSL >> Client Select the profile that will be used for client authentication Scroll until you reach Client Authentication From the drop down menu for Trusted Certificate Authorities, select the bundle created in the previous steps. From the drop down menu for Advertised Certificate Authorities, select the bundle created in the previous steps. Click Update The Trusted Certificate Authorities setting is required only if the BIG-IP system performs Client Certificate Authentication. This setting is specifies the BIG-IP system's Trusted Certificate Authorities store (the CAs that the BIG-IP system trusts when the system verifies a client certificate that is presented during Client Certificate Authentication). The Advertised Certificate Authorities setting is optional. You can use it to specify the CAs that the BIG-IP system advertises as trusted when soliciting a client certificate for client certificate authentication. If the Client Certificate setting is configured to Require or Request, you can configure the Advertised Certificate Authorities setting to send clients a list of CAs that the server is likely to trust. At this point you have successfully created, imported and assigned your new certificate bundle. If you would like to view a complete guide on configuring smart card authentication, please view my articles on DevCentral. Until next time!F5 iWorkflow and Cisco ACI : True application centric approach in application deployment (End Of Life)
The F5 and Cisco APIC integration based on the device package and iWorkflow is End Of Life. The latest integration is based on the Cisco AppCenter named ‘F5 ACI ServiceCenter’. Visit https://f5.com/cisco for updated information on the integration. On June 15 th , 2016, F5 released iWorkflow version 2.0, a virtual appliance platform designed to deploy application with greater agility and consistency. F5 iWorkflow Cisco APIC cloud connector provides a conduit allowing APIC to deploy F5 iApps on BIG-IP. By leveraging iWorkflow, administrator has the capability to customize application template and expose it to Cisco APIC thru iWorkflow dynamic device package. F5 iWorkflow also support Cisco APIC Chassis and Device Manager features. Administrator can now build Cisco ACI L4-L7 devices using a pair of F5 BIG-IP vCMP HA guest with a iWorkflow HA cluster. The following 2-part video demo shows: (1) How to deploy iApps virtual server in BIG-IP thru APIC and iWorkflow (2) How to build Cisco ACI L4-L7 devices using F5 vCMP guests HA and iWorkflow HA cluster F5 iWorkflow, BIG-IP and Cisco APIC software compatibility matrix can be found under: https://support.f5.com/kb/en-us/solutions/public/k/11/sol11198324.html Check out iWorkflow DevCentral page for more iWorkflow info: https://devcentral.f5.com/s/wiki/iworkflow.homepage.ashx You can download iWorkflow from https://downloads.f5.com
Automate BIG-IP in customer environments using Ansible
There are a lot of technical resources on how Ansible can be used to automte the F5 BIG-IP. A consolidated list of links to help you brush up on Ansible as well as help you understand the Ansible BIG-IP solution Getting started with Ansible Ansible and F5 solution overview F5 and Ansible Integration - Webinar Dig deeper into F5 and Ansible Integration - Webinar I am going to dive directly into how customers are using ansible to automate their infrastructure today. If you are considering using Ansible or have already gone through a POC maybe a few of these use cases will resonate with you and you might see use of them in your environment. Use Case: Rolling application deployments Problem Consider a web application whose traffic is being load balanced by the BIG-IP. When the web servers running this application need to be updated with a new software package, an organization would consider going in for a rolling deployment where rather than updating all servers or tiers simultaneously. This means, the organization installs the updated software package on one server or subset of servers at a time. The organization would need to bring down one server at a time to have minimal traffic disruption. Solution This is a repeatitive and time consuming task for an organization considering there are newer updates coming out every so often. Ansible’s F5 modules can be used to automate operations like disabling a node (pool member), performing an update on that node and then bring that node back into service. This workflow is applicable for every node member of the pool sequentially resulting in zero down time for the application Modules bigip_ltm_facts bigip_node Sample - name: Update software on Pool Member - "{{node_name}}" hosts: bigip gather_facts: false vars: pool_name: "{{pool_name}}" node_name: "{{node_name}}" tasks: - name: Query BIG-IP facts for Pool Status - "{{pool_name}}" bigip_facts: validate_certs: False server: "{{ bigip_ip_address }}" user: "{{ bigip_username}}" bigip_password: "{{ bigip_password}}" include: "pool" delegate_to: localhost register: bigip_facts - name: Assert that Pool - "{{pool_name}}" is available before disabling node assert: that: - "'AVAILABILITY_STATUS_GREEN' in bigip_facts['ansible_facts']['pool']['/Common/{{iapp_name}}/{{pool_name}}']['object_status']['availability_status']|string" msg: "Pool is NOT available DONOT want to disable any more nodes..Check your BIG-IP" - name: Disable Node - "{{node_name}}" bigip_node: server: "{{ bigip_ip_address }}" user: "{{ bigip_username}}" bigip_password: "{{ bigip_password}}" partition: "Common" name: "{{node_name}}" state: "present" session_state: "disabled" monitor_state: "disabled" delegate_to: localhost - name: Get Node facts - "{{node_name}}" bigip_facts: validate_certs: False server: "{{ bigip_ip_address }}" user: "{{ bigip_username}}" bigip_password: "{{ bigip_password}}" include: "node" delegate_to: localhost register: bigip_facts - name: Assert that node - "{{node_name}}" did get disabled assert: that: - "'AVAILABILITY_STATUS_RED' in bigip_facts['ansible_facts']['node']['/Common/{{node_name}}']['object_status']['availability_status']|string" msg: "Pool member did NOT get DISABLED" - name: Perform software update on node - "{{node_name}}" hosts: "{{node_name}}" gather_facts: false vars: pool_name: "{{pool_name}}" node_name: "{{node_name}}" tasks: - name: "Update 'curl' package" apt: name=curl state=present - name: Enable Node hosts: bigip gather_facts: false vars: pool_name: "{{pool_name}}" node_name: "{{node_name}}" tasks: - name: Enable Node - "{{node_name}}" bigip_node: server: "{{ bigip_ip_address }}" user: "{{ bigip_username}}" bigip_password: "{{ bigip_password}}" partition: "Common" name: "{{node_name}}" state: "present" session_state: "enabled" monitor_state: "enabled" delegate_to: localhost Use Case: Deploying consistent policies across different environment using F5 iApps Problem Consider an organization has many different environments (development/QA/Production). Each environment is a replica of each other and has around 100 BIG-IP’s in each environment. When a new application is added to one environment it needs to be added to other environments in a fast, safe and secure manner. There is also a need to make sure the virtual server bought online adheres to all the traffic rules and security policies. Solution To ensure that the virtual server is deployed correctly and efficiently, the entire application can be deployed on the BIG-IP using the iApps module. iApps also has the power to reference ASM policies hence helping to consistently deploy an application with the appropriate security policies Modules bigip_iapp_template bigip_iapp_service Sample - hosts: localhost tasks: - name: Get iApp from Github get_url: url: "{{ Git URL from where to download the iApp }}" dest: /var/tmp validate_certs: False - name: Upload iApp template to BIG-IP bigip_iapp_template: server: "{{ bigip_ip_address }}" user: "{{ bigip_username }}" password: "{{ bigip_password }}" content: "{{ lookup('file', '/var/tmp/appsvcs_integration_v2.0.003.tmpl') }}" #Name of iApp state: "present" validate_certs: False delegate_to: localhost - name: Deploy iApp bigip_iapp_service: name: "HTTP_VS_With_L7Firewall" template: "appsvcs_integration_v2.0.003" parameters: "{{ lookup('file', 'final_iapp_with_asm.json') }}" #JSON blob for body content to the iApp server: "{{ bigip_ip_address }}" user: "{{ bigip_username}}" password: "{{ bigip_password }}" state: "present" delegate_to: localhost Use Case: Disaster Recovery Problem All organizations should have a disaster recovery plan in place incase of a catastrophic failure resulting in loss of data including BIG-IP configuration data. Re-configuring the entire infrastructure from scratch can be an administrative nightmare. The procedure in place for disaster recovery can also be used for migrating data from one BIG-IP to another as well as for performing hardware refresh and RMA’s. Solution Use BIG-IP user configuration set (UCS) configuration file to restore the configuration on all the BIG-IP’s and have your environment back to its original configuration in minutes. Modules bigip_ucs Sample --- - name: Create UCS file hosts: bigip gather_facts: false tasks: - name: Create ucs file and store it bigip_ucs: server: "{{ bigip_ip_address }}" user: "{{ bigip_username }}" password: "{{ bigip_password }}" ucs: "/root/test.ucs" state: "installed" delegate_to: localhost Use Case: Troubleshooting Problem Any problem on the BIG-IP for example a backend server not receiving traffic or a virtual server dropping traffic unexpectedly or a monitor not responding correctly needs extensive troubleshooting. These problems can be hard to pin point and need an expert to debug and look through the logs. Solution Qkview is a great utility on the BIG-IP which that an administrator can use to automatically collect configuration and diagnostic information from BIG-IP and other F5 systems. Use this ansible module and run it against all BIG-IP’s in your network and collect the diagnostic information to pass it onto to F5 support. Modules bigip_qkview Sample - name: Create qkview hosts: bigip gather_facts: false tasks: - name: Generate and store qkview file bigip_qkview: server: "{{ bigip_ip_address }}" user: "{{ bigip_username }}" password: "{{ bigip_password }}" asm_request_log: "no" dest: "/tmp/localhost.localdomain.qkview" validate_certs: "no" delegate_to: localhost Conclusion These are just some of the use cases that can be tackled using our BIG-IP ansible modules. We have several more modules in Ansible 2.4 release that the ones mentioned above which can help in other scenarios. To view a complete list of BIG-IP modules available in ansible 2.4 release click here Module overview at a glance BIG-IP modules in Ansible release 2.3 New BIG-IP modules in Ansible release 2.4 To get started and save time download a BIG-IP onboarding ansible role from ansible galaxy and run the playbook against your BIG-IP
Rate Limiting SSL VPN User Traffic
With lots of people working at home, contention on VPNs is a real problem at the moment - license capacity, device CPU and throughput rate. One way to deal with this is to apply rate limits to user traffic. This can be done in a number of ways - applying a BWC policy in the Access Policy, using Traffic Classifiers, etc but I like simple solutions so i'm going to show you how to do it with virtual servers and iRules, and to take the easy way out you can use my iApp to do it for you! For a start, let's look at an SSL VPN in a bit more detail. Tunnels! The tunnel part of the SSL VPN is based around the Connectivity Profile - this specifies settings like compression and VPN settings. When you create a Connectivity Profile, this also creates a tunnel interface This tunnel interface is used as an internal connector so that outgoing traffic can be managed - the same function is used with HTTP explicit proxies which use http-tunnel. This is a very powerful feature - this means that we can create a virtual server which listens on that tunnel interface to be able to capture VPN user traffic before it leaves the BIG-IP. Bandwidth Controllers We have two types of bandwidth controller policy - Static and Dynamic. A Static policy sets the overall rate of traffic allowed, a dynamic policy allows us to set an overall rate but also a rate per user flow. For instance, we could allow ALL VPN traffic to be 1Gbps but each individual traffic flow within that could be limited to 1Mbps. iRules To apply the policy to the user traffic we are going to use an iRule with the BWC::policy command - this will set the policy on this flow for both uplink and downlink traffic in two different events - CLIENT_ACCEPTED and SERVER_CONNECTED when CLIENT_ACCEPTED { BWC::policy attach /Common/bwc-10M "[IP::remote_addr]:[TCP::remote_port]" } when SERVER_CONNECTED { BWC::policy attach /Common/bwc-10M "[IP::remote_addr]:[TCP::remote_port]" } Obviously the TCP::remote_port would be UDP::remote_port in a UDP virtual server. Putting it together Below you can see the virtual server configuration which I created using my iApp ltm virtual Common/vpn-1.app/vs_bwc_vpn-1_tcp_default { app-service /Common/vpn-1.app/vpn-1 creation-time 2020-04-29:10:26:39 destination Common/0.0.0.0:any ip-protocol tcp last-modified-time 2020-04-29:11:32:33 mask any profiles { Common/tcp { } } rules { Common/vpn-1.app/rule_bwc_vpn-1_tcp_default } serverssl-use-sni disabled source 0.0.0.0/0 source-address-translation { pool Common/snat-1 type snat } translate-address disabled translate-port disabled vlans { Common/connectivity-1 } vlans-enabled vs-index 7 } ltm virtual Common/vpn-1.app/vs_bwc_vpn-1_udp_default { app-service /Common/vpn-1.app/vpn-1 creation-time 2020-04-29:10:26:39 destination Common/0.0.0.0:any ip-protocol udp last-modified-time 2020-04-29:11:32:33 mask any profiles { Common/udp { } } rules { Common/vpn-1.app/rule_bwc_vpn-1_udp_default } serverssl-use-sni disabled source 0.0.0.0/0 source-address-translation { pool Common/snat-1 type snat } translate-address disabled translate-port disabled vlans { Common/connectivity-1 } vlans-enabled vs-index 6 } It works! iperf with no bandwidth controller $ iperf -c 10.20.20.3 ------------------------------------------------------------ Client connecting to 10.20.20.3, TCP port 5001 TCP window size: 64.0 KByte (default) ------------------------------------------------------------ [ 3] local 10.20.20.131 port 5957 connected with 10.20.20.3 port 5001 [ ID] Interval Transfer Bandwidth [ 3] 0.0-10.0 sec 184 MBytes 154 Mbits/sec iperf with a 10Mbps bandwidth controller applied $ iperf -c 10.20.20.3 ------------------------------------------------------------ Client connecting to 10.20.20.3, TCP port 5001 TCP window size: 64.0 KByte (default) ------------------------------------------------------------ [ 3] local 10.20.20.131 port 6066 connected with 10.20.20.3 port 5001 [ ID] Interval Transfer Bandwidth [ 3] 0.0-10.2 sec 12.1 MBytes 9.98 Mbits/sec Make it easy I've shown you there how to put together the constituent parts yourself but brought to you by the magic of iApps, you can do it all automagically. You can use the iApp at APM VPN Bandwidth Controller iApp - just create the BWC policy you want to apply beforehand and run the iApp. You can even treat certain protocols differently - imagine if you want to limit HTTPS to 1Mbps but allow other traffic to have 10Mbps ( because a 1 second delay in a web page load is not noticeable but a 1 second delay in a Zoom session is very noticeable! )Getting Started With iApps: Components
Our last article, Getting Started with iApps: Conceptual Overview we breezed through iApps are and how they can benefit deployment and management of your nastiest applications. That’s fine and dandy, but the real benefit of iApps is through creation and customization of your very own iApps. To get you started, it’s helpful to understand how iApps are put together, specifically the components involved. This article will get you familiar with the internal workings of iApps and by doing so, lower the intimidation factor they sometimes cause. The iApps Framework: Templates iApp templates generate an application servicefrom user answers related totheir applicationrequirements. Templates provide a procedural graphic interface and context-sensitive help for the administrator. A new deployment uses a a single template to create an interface and guide the user through the configuration process, deploying the configuration when published. For common-deployed infrastructure, a well-defined template can be reused for multiple application services creation. During deployment a template can: Create new configuration objects Reference existing BIG-IP configuration objects, i.e. profiles or monitors Create additional configuration objects dynamically based on template requirements. For example, if an iApp creates a pool member with an IP address that does not already exist as a node, the BIG-IP will create the node automatically Objects created by templates are identified as components of the application service, and can be viewed on the deployed application service component tab. There are 5 sections to make up an iApp Template: Attributes Required BIG-IP modules Min/Max BIG-IP version Presentation Defines User Interface Application Presentation Language (APL is used to build the interface) Implementation Processing code TCL and TMSH commands Macro Creates an iRule dynamically Help HTML-based help tab Inline help (in presentation section) iApps Templates: Attributes The template attributes defined by the developer designate what versions and modules the template needs to execute one or more of the commands defined int presentation and implementation sections. These include: System-supplied property: Indicates if the template is provided with the installed version of BIG-IP or if it was copied/imported elsewhere. This is a read-only field. Required BIG-IP Modules property: This is used to set the required modules that must be provisioned before the template can be used by an application service. Minimum BIG-IP Version property: Displays minimum version of BIG-IP the template supports. If the system does not meet the min requirement, the system will post an invalid-template alert, and does not include make that template available for deployment. Maximum BIG-IP Version property: Displays the maximum version of software supported by the template. Similar to the above minimum version, BIG-IP will issue the same alert and mark it unavailable for deployment. Verification property: Indicates if the template is verified by F5 Support. iApps Templates: Presentation Using the Application Presentation Language (APL), the presentation section builds the user interface for the iApps template being deployed. The user is given a series of questions and options, and answers provided determine the configuration objects created and/or referenced. The APL describes what questions to ask, in what order to ask, how the questions are presented (free form, drop down, lists…), and the names of the variables used to store configuration data prior to publishing the template. Below we can see the APL code defined in F5 NIST SP800-53 RC4 template for the question related to access control. sc10 "Idle Timeouts for Management Access -- AC-2(5), SC-10" sc10.purpose "" sc10.mins "How many minutes for each Idle Timeout value? " sc10.mins_help "" sc10.mins.timeout_gui "Management GUI" sc10.mins.timeout_ssh "SSH" sc10.mins.timeout_console "Console" sc10.mins.timeout_tmsh "TMSH" section sc10 { message purpose "Configure idle timeouts for management access facilities. For each facility the value zero selects a 12-hour timeout." row mins { string timeout_gui required display "small" validator "nonnegativenumber" default tcl { set tmp [tmsh::run_proc nist80053:my_item \ /sys httpd auth-pam-idle-timeout] return [expr {int(($tmp + 59) / 60)}] } string timeout_ssh required display "small" validator "nonnegativenumber" default tcl { set tmp [tmsh::run_proc nist80053:my_item \ /sys sshd inactivity-timeout] return [expr {int(($tmp + 59) / 60)}] } string timeout_console required display "small" validator "nonnegativenumber" default tcl { set tmp [tmsh::run_proc nist80053:my_item \ /sys global-settings console-inactivity-timeout] return [expr {int(($tmp + 59) / 60)}] } string timeout_tmsh required display "small" validator "nonnegativenumber" default tcl { set tmp [tmsh::run_proc nist80053:my_item \ /cli global-settings idle-timeout] return [expr {($tmp eq "disabled") ? 0 : $tmp}] } } optional (intro.help == "show") { message mins_help "For each field, type the number of minutes of idle time that should elapse before the session times out. Using a value of zero (0) sets the timeout to 12 hours (720 minutes)." } } iApps Template: Implementation Using our ol’ standby TCL, this section of the template is written in the TMSH scripting language. This is the programmatic heart of the iApp template and builds the configuration needed to run your application as a unique service. We’re using the same F5 NIST SP800-53 iApp template and the Implementation code shown below is responsible for converting the answers defined in the presentation section into BIG-IP usable commands. #various login timeout settings if {[set tmp [expr {$::sc10__mins__timeout_gui * 60}]] == 0} { set tmp 43200 } elseif {$tmp < 120} { set tmp 120 } iapp_conf "modify /sys httpd auth-pam-idle-timeout ${tmp}" iapp_conf "modify /sys httpd auth-pam-dashboard-timeout on" if {[set tmp [expr {$::sc10__mins__timeout_ssh * 60}]] == 0} { set tmp 43200 } iapp_conf "modify /sys sshd inactivity-timeout ${tmp}" if {[set tmp [expr {$::sc10__mins__timeout_console * 60}]] == 0} { set tmp 43200 } iapp_conf "modify /sys global-settings console-inactivity-timeout ${tmp}" if {[set tmp $::sc10__mins__timeout_tmsh] == 0} { set tmp 720 } iapp_conf "modify /cli global-settings idle-timeout ${tmp}" iApps Templates: Help The help section is html defined and used to either give a large overview of the iApp template being used. The snippet below shows inline help questions that the user might need for specific questions they may not be sure of. This can also be used to help define formatting for more complex questions, such as an LDAP baseDN or LDAP filter to be used. <h6>SC-7 - Boundary Protection</h6> <p>This iApp lets you manage the IP subnets from which BIG-IP management may be accessed as well as services accessible on self IP’s.</p> <h6>SC-10 - Network Disconnect</h6> <p>This iApp exposes several timeout settings for access to the system.</p> <h6>SC-17 - Public Key Infrastructure Certificates</h6> <p>This iApp does not manage TLS/SSL PKI certificates or cryptographic material as such. However, you can select the appropriate certificates and keys for single-ended and mutual authentication of connections to external authentication/directory services.</p> The iApps Framework: Application Services We’ve configured an iApps Template, and clicked Finished. This starts the deployment and creation process of converting your answers into a unique application service and if we have good connections and all services are up, a functional application. A running application service can be administered by clicking reconfigure after selecting it in the iApps Application Services menu. From there, the same questions previously answered during deployment are available for modification. This is useful when IP’s or certificate profiles change and simple and quick updates are needed. The Application Service also provides a Components view that lists each object in use to manage the specific application service and if applicable, it’s operational status. Below is a completed LDAP application service. Note the familiar red diamonds because none of the LDAP servers referenced in this service are available. I’m a bad admin, I know. Also note that I created a CA and made wicked awesome certs just for this example (really I accidentally deleted my old virtual machine with the previous CA). iApps Template: Availability and Support Some of you that frequent DevCentral know there’s a lot of information on iApps available in Codeshare and the Wiki (The wiki is managed by the iApps team so make sure to check it out). However, DevCentral is not on officialsupport channelso here’s a quick breakdown of where to get your variously supported/unsupported iApps.. iApps on the BIG-IP system: Those are created and supported by F5. Enjoy iApps on F5 Support: If there is no RC status (release candidate) then they are supported by F5. iApps on DevCentral’s Codeshare: These are usuallyworks-in-progress, release candidate, user submitted, or F5 submitted; but not certified;none are officially supported. These are use-at-your-own risk but of course you have dev and test environments for just such occasions. You wouldn’t DARE test out an unsupported iApp off DevCentral in your production environment right??? That wasn’t so bad, was it. Now that you have a better understanding of what goes into an iApp, they’re not so intimidating. If you’ve done any iRule coding, you probably have an urge to start modifying one after finishing this article. Check out the different iApps out there on DevCentral and see if you have any upcoming deployments that may benefit from using iApps. Get your developers involved too as iApps are a natural progression in your DevOp’ish plans. Tomorrow our very own Jason “Lord of the Dance and TCL” Rahm will cover modifying and creating iApps so please stay tuned and get your dev hat ready.Getting Started with iApps: A Conceptual Overview
tl;dr - iApps provide admins and service desks a template solution for application deployment and management services. Deploying and managing applications require a lot of information across several disciplines. Architects have their holistic view of the application ecosystem and relevant lifecycles. Developers have their granular relationship with each application under their umbrella. Networks admins make sure applications are behaving appropriately on the network instead of hijacking QoS classes or hijacking DNS. Then there are those missing details that no one wants to own until something breaks (looking at you Java CA store). Originally F5 introduced deployment guides to help administrators understand the requirements and configurations needed to deploy popular applications behind BIG-IP. However, after the deployment was complete, those configurations were still managed through object types alone (e.g. virtual servers, pools, profiles, iRules, monitors). That can get quite tedious when you have hundreds of applications on a single BIG-IP stack. Someone somewhere said “Wouldn’t it be nice if we could have an application-based view of all the different objects that help us deploy, manage, and secure each application”? Enter iApps Introduced in BIG-IP 11.0, iApps are a customizable framework for deploying and managing application as a service. Using out-of-the-box templates, administrators can deploy commonly-used applications such as Oracle, SAP, or Exchange by completing a series of questions that relate to their management and infrastructure needs. Rather than create a bunch of virtual servers, followed by a handful of monitors, then a plethora of whatever, the responses to iApps questions create all of the BIG-IP objects needed to properly run your application. The iApps application service becomes the responsible manager of all virtual servers, monitors, policies, profiles, and iRules required to run. Consolidating these into a single view makes management and troubleshooting much easier to handle. iApps Framework iApps consist of two main elements, the template and application services created by publishing a template. We’ll dive into this in our next article, Getting Started With iApps: Components. Templates: The base configuration object which contains the layout and scripting used to configure and publish application instances. Some templates are prebuilt and included in BIG-IP, while others can be download from DevCentral (are not officially supported) or F5 support (certified and supported). Developer-oriented teams can also build custom templates for frequently used configurations or services. Application Service: An application service is the result of using an iApps template to drive the configuration process. The Administrator uses the configuration utility to create a new application service from the selected iApps template. Created objects are grouped into components of the application service and are managed accordingly. The iApps Advantage iApps are not for everyone. If you like keeping tribal control over your BIG-IP ecosystem or if you like naming virtual servers after your pets, iApps may not be for you. iApps do have an advantage if you want to templatize your deployment scenarios or wish to allow other administrators access to the services they manage. iApps reduce a lot of the mystique and intimidation a lengthy set of profiles, policies, and pools can sometimes cause to the new or intermediate administrator. Above we show an example of building a highly available LDAP namespace for internal applications with the default built-in LDAP iApps template. By providing a certificate and and answering a few questions, an LDAP environment is created for all of your internal directory authentication or lookup requirements. From there, modifying the configuration is easy as selecting the Reconfigure tab in the existing application service. Changing settings within iApps Sometimes you just want a template to assist with application deployment and from there you’re perfectly fine managing the individual object types. The Component view will show you all objects affected by the application service but if you try to apply a change, you’ll receive an error similar to: This is by design because the iApps application service is the rightful owner of the system object and shouldn’t be edited directly. However in certain cases you don’t the iApp anymore or want more granular control of some features the iApps my not have, there is an option. Each application service published via iApps have a Properties tab which allow you to disable the Strict Updates method of management. Unchecked, each object is configurable on it’s own but will deviate from the templates last known state. Some administrators prefer to operate this way, only using the iApp as a deployment method, and that’s perfectly fine. We’re leaving your application management style and method up to you. As BIG-IP expands to cover more of the application landscape, people are increasingly taking advantage of more programmatic features and iApps is no exception. Allowing our administrators to improve their ease of deployment and use is why iApps exist and we’ll continue to develop and improve these features. Our next article Getting Started with iApps: Components will dive into more detail on the properties required to create and manage iApps. Take the time to get to know iApps, they’re your ally for keeping your applications in order.
F5 in AWS Part 4 - Orchestrating BIG-IP Application Services with Open-Source tools
Updated for Current Versions and Documentation Part 1 : AWS Networking Basics Part 2: Running BIG-IP in an EC2 Virtual Private Cloud Part 3: Advanced Topologies and More on Highly-Available Services Part 4: Orchestrating BIG-IP Application Services with Open-Source Tools Part 5: Cloud-init, Single-NIC, and Auto Scale Out of BIG-IP in v12 The following post references code hosted at F5's Github repository f5networks/aws-deployments. This code provides a demonstration of using open-source tools to configure and orchestrate BIG-IP. Full documentation for F5 BIG-IP cloud work can be found at Cloud Docs: F5 Public Cloud Integrations. So far we have talked above AWS networking basics, how to run BIG-IP in a VPC, and highly-available deployment footprints. In this post, we’ll move on to my favorite topic, orchestration. By this point, you probably have several VMs running in AWS. You’ve lost track of which configuration is setup on which VM, and you have found yourself slowly going mad as you toggle between the AWS web portal and several SSH windows. I call this ‘point-and-click’ purgatory. Let's be blunt, why would you move to cloud without realizing the benefits of automation, of which cloud is a large enabler. If you remember our second article, we mentioned CloudFormation templates as a great way to deploy a standardized set of resources (perhaps BIG-IP + the additional virtualized network resources) in EC2. This is a great start, but we need to configure these resources once they have started, and we need a way to define and execute workflows which will run across a set of hosts, perhaps even hosts which are external to the AWS environment. Enter the use of open-source configuration management and workflow tools that have been popularized by the software development community. Open-source configuration management and AWS APIs Lately, I have been playing with Ansible, which is a python-based, agentless workflow engine for IT automation. By agentless, I mean that you don’t need to install an agent on hosts under management. Ansible, like the other tools, provides a number of libraries (or “modules”) which provide the ability to manage a diverse collection of remote systems. These modules are typically implemented through the use of API calls, often over HTTP. Out of the box, Ansible comes with several modules for managing resources in AWS. While the EC2 libraries provided are useful for basic orchestration use cases, we decided it would be easier to atomically manage sets of resources using the CloudFormation module. In doing so, we were able to deploy entire CloudFormation stacks which would include items like VPCs, networking elements, BIG-IP, app servers, etc. Underneath the covers, the CloudFormation: Ansible module and our own project use the python module to interact with AWS service endpoints. Ansible provides some basic modules for managing BIG-IP configuration resources. These along with libraries for similar tools can be found here: Ansible Puppet SaltStack In the rest of this post, I’ll discuss some work colleagues and I have done to automate BIG-IP deployments in AWS using Ansible. While we chose to use Ansible, we readily admit that Puppet, Chef, Salt and whatever else you use are all appropriate choices for implementing deployment and configuration management workflows for your network. Each have their upsides and downsides, and different tools may lend themselves to different use cases for your infrastructure. Browse the web to figure out which tool is right for you. Using Standardized BIG-IP Interfaces Speaking of APIs, for years F5 has provided the ability to programmatically configure BIG-IP using iControlSOAP. As the audiences performing automation work have matured, so have the weapons of choice. The new hot ticket is REST (Representational State Transfer), and guess what, BIG-IP has a REST interface (you can probably figure out what it is called). Together, iControlSOAP and iControlREST give you the power to manage nearly every configuration element and feature of BIG-IP. These interfaces become extremely powerful when you combine them with your favorite open-source configuration management tool and a cloud that allows you to spin up and down compute and networking resources. In the project described below, we have also made use of iApps using iControlRest as a way to create a standard virtual server configuration with the correct policies and profiles. The documentation in Github describes this in detail, but our approach shows how iApps provide a strongly supported approach for managing network policy across engineering teams. For example, imagine that a team of software engineers has written a framework to deploy applications. You can package the network policy into iApps for various types of apps, and pass these to the teams writing the deployment framework. Implementing a Service Catalog To pull the above concepts together, a colleague and I put together the aws-deployments project.The goal was to build a simple service catalog which would enable a user to deploy a containerized application in EC2 with BIG-IP network services sitting in front. This is example code that is not supported by F5 support but is a proof of concept to show how you can fully automate production-like deployments in AWS. Some highlights of the project include: Use of iControlRest and iControlSoap within Ansible playbooks to setup advanced topologies of BIG-IP in AWS. Automated deployment of a basic ASM web application firewall policy to protect a vulnerable web app (Hackazon. Use of iApps to manage virtual server configurations, including the WAF policy mentioned above. Figure 1 - Generic Architecture for automating application deployments in public or private cloud In examination of the code, you will see that we provide the opportunity to provision all the development models outlined in our earlier post (a single standalone VE, standalones BIG-IP VEs striped availability zones, clusters within an availability zone, etc). We used Ansible and the interfaces on BIG-IP to orchestrate the workflows assoiated with these deployment models. To perform the clustering step, we have used the iControlSoap interface on BIG-IP. The final set of technology used is depicted in Figure 3. Figure 2 - Technologies used in the aws-deployments project on Github Read the Code and Test It Yourself All the code I have mentioned is available at f5networks/aws-deployments. We encourage you to download and run the code for yourself. Instructions for setting up a development environment which includes the necessary dependencies is easy. We have packaged all the dependencies for use with either Vagrant or Docker as development tools. The instructions for either of these approaches can be found in the README.md or in the /docs directory. The following video shows an end-to-end usage example. (Keep in mind that the code has been updated since this video was produced). At the end of the day, our goal for this work was to collect customer feedback. Please provide some by leaving a comment below, or by filing ‘pull requests’ or ‘issues’ in Github. In the next few weeks, we will be updating the project to include the Hackazon app mentioned above, show how to cluster BIG-IP across availability zones, and how to deploy an ASM profile with an iApp. Have fun!
