AWS

133 Topics

Deploying F5 NGINX Plus Graviton-powered Containers as AWS ECS Fargate Tasks
This tutorial guides users through deploying F5 NGINX Plus on AWS ECS Fargate using Graviton-powered containers, covering environment setup, custom image creation, and service deployment.
Tony_Marfil
Sep 12, 2024 Place Technical Articles
203Views
1like
0Comments
Using BIG-IP GTM to Integrate with Amazon Web Services
This is the latest in a series of DNS articles that I've been writing over the past couple of months. This article is taken from a fantastic solution that Joe Cassidy developed. So, thanks to Joe for developing this solution, and thanks for the opportunity to write about it here on DevCentral. As a quick reminder, my first six articles are: Let's Talk DNS on DevCentral DNS The F5 Way: A Paradigm Shift DNS Express and Zone Transfers The BIG-IP GTM: Configuring DNSSEC DNS on the BIG-IP: IPv6 to IPv4 Translation DNS Caching The Scenario Let's say you are an F5 customer who has external GTMs and LTMs in your environment, but you are not leveraging them for your main website (example.com). Your website is a zone sitting on your windows DNS servers in your DMZ that round robin load balance to some backend webservers. You've heard all about the benefits of the cloud (and rightfully so), and you want to move your web content to the Amazon Cloud. Nice choice! As you were making the move to Amazon, you were given instructions by Amazon to just CNAME your domain to two unique Amazon Elastic Load Balanced (ELB) domains. Amazon’s requests were not feasible for a few reasons...one of which is that it breaks the RFC. So, you engage in a series of architecture meetings to figure all this stuff out. Amazon told your Active Directory/DNS team to CNAME www.example.com and example.com to two AWS clusters: us-east.elb.amazonaws.com and us-west.elb.amazonaws.com. You couldn't use Microsoft DNS to perform a basic CNAME of these records because of the BIND limitation of CNAME'ing a single A record to multiple aliases. Additionally, you couldn't point to IPs because Amazon said they will be using dynamic IPs for your platform. So, what to do, right? The Solution The good news is that you can use the functionality and flexibility of your F5 technology to easily solve this problem. Here are a few steps that will guide you through this specific scenario: Redirect requests for http://example.com to http://www.example.com and apply it to your Virtual Server (1.2.3.4:80). You can redirect using HTTP Class profiles (v11.3 and prior) or using a policy with Centralized Policy Matching (v11.4 and newer) or you can always write an iRule to redirect! Make www.example.com a CNAME record to example.lb.example.com; where *.lb.example.com is a sub-delegated zone of example.com that resides on your BIG-IP GTM. Create a global traffic pool “aws_us_east” that contains no members but rather a CNAME to us-east.elb.amazonaws.com. Create another global traffic pool “aws_us_west” that contains no members but rather a CNAME to us-west.elb.amazonaws.com. The following screenshot shows the details of creating the global traffic pools (using v11.5). Notice you have to select the "Advanced" configuration to add the CNAME. Create a global traffic Wide IP example.lb.example.com with two pool members “aws_us_east” and “aws_us_west”. The following screenshot shows the details. Create two global traffic regions: “eastern” and “western”. The screenshot below shows the details of creating the traffic regions. Create global traffic topology records using "Request Source: Region is eastern" and "Destination Pool is aws_us_east". Repeat this for the western region using the aws_us_west pool. The screenshot below shows the details of creating these records. Modify Pool settings under Wide IP www.example.com to use "Topology" as load balancing method. See the screenshot below for details. How it all works... Here's the flow of events that take place as a user types in the web address and ultimately receives the correct IP address. External client types http://example.com into their web browser Internet DNS resolution takes place and maps example.com to your Virtual Server address: IN A 1.2.3.4 An HTTP request is directed to 1.2.3.4:80 Your LTM checks for a profile, the HTTP profile is enabled, the redirect request is applied, and redirect user request with 301 response code is executed External client receives 301 response code and their browser makes a new request to http://www.example.com Internet DNS resolution takes place and maps www.example.com to IN CNAME example.lb.example.com Internet DNS resolution continues mapping example.lb.example.com to your GTM configured Wide IP The Wide IP load balances the request to one of the pools based on the configured logic: Round Robin, Global Availability, Topology or Ratio (we chose "Topology" for our solution) The GTM-configured pool contains a CNAME to either us_east or us_west AWS data centers Internet DNS resolution takes place mapping the request to the ELB hostname (i.e. us-west.elb.amazonaws.com) and gives two A records External client http request is mapped to one of the returned IP addresses And, there you have it. With this solution, you can integrate AWS using your existing LTM and GTM technology! I hope this helps, and I hope you can implement this and other solutions using all the flexibility and power of your F5 technology.
ltwagnon
Sep 04, 2024 Place Technical Articles
3KViews
1like
14Comments
Customer-driven Site Deployment Using AWS and F5 Distributed Cloud Terraform Modules
Introduction and Problem Scope F5 Distributed Cloud Mesh’s Secure Networking provides connectivity and security services for your applications running on the Edge, Private Clouds, or Public Clouds. This simplifies the deployment and configuration of connectivity and security services for your Multi-Cloud and Edge Cloud deployment needs across heterogeneous environments. F5 Distributed Cloud Services leverages the “Site” construct to deploy our Secure Mesh or AppStack Site instances to manage workloads. A Site could be a customer location like AWS, Azure, GCP (Google Cloud Platform), private cloud, or an edge site. To run F5 Distributed Cloud Services, the site needs to be deployed with one or more instances of F5 Distributed Cloud Node, a software appliance that is managed by F5 Distributed Cloud Console. This site is where customer applications and F5 Distributed Cloud services are running. To deploy a Node, different options are available: Customer deployment topology description We will explain the above steps in the context of a greenfield deployment, the Terraform scripts of which are available here. The corresponding logical topology view of this deployment is shown in Fig.2. This deployment scenario instantiates the following resources: Single-node CE cluster AWS SLO interface AWS VPC AWS SLO interface subnet AWS route tables AWS Internet Gateway Assign AWS EIP to SLO The objective of this deployment is to create a Site with a single CE node in a new VPC for the provided AWS region and availability zone. The CE will be created as an AWS EC2 instance. An AWS subnet is created within the VPC. CE Site Local Outside (SLO) interface will be attached to VPC subnet and the created EC2 instance. SLO is a logical interface of a site (CE node) through which reachability is achieved to external (e.g. Internet or other services outside the public cloud site). To enable reachability to the Internet, the default route of the CE node will point to the AWS Internet gateway. Also, the SLO will be configured with an AWS External IP address (Elastic IP). Fig.2. Customer Deployment Topology in AWS List of terraform input parameters provided in vars file Parameters must be customized to adapt to the customer environment. The definition of the parameters in the “terraform.tfvars” show in below table. Parameters Definitions owner Identifies the email of the IT manager used to authenticate to the AWS system project_prefix Prefix that will be used to identify the resource objects in AWS and XC. project_suffix The suffix that will be used to identify the site’s resources in AWS and XC ssh_public_key_file Local file system’s path to ssh public key file f5xc_tenant Full F5XC tenant name f5xc_api_url F5XC API url f5xc_cluster_name Name of the Cluster f5xc_api_p12_file Local file system path to api_cert_file (downloaded from XC Console) aws_region AWS region for the XC Site aws_existing_vpc_id Existing VPC ID (brownfield) aws_vpc_cidr_block CIDR Block of the VPC aws_availability_zone AWS Availability Zone (a) aws_vpc_slo_subnet_node0 AWS Subnet in the VPC for the SLO subnet Configuring other environmental variables Export the following environment variables in the working shell, setting it to customer’s deployment context. Environment Variables Definitions AWS_ACCESS_KEY AWS Access key for authentication AWS_SECRET_ACCESS_KEY AWS Secret key for authentication VES_P12_PASSWORD XC P12 Password from Console TF_VAR_f5xc_api_p12_cert_password Same as VES_P12_PASSWORD Deploy Topology Deploy the topology with: terraform init terraform plan terraform deploy –auto-approve And monitor the status of the Sites on the F5 Distributed Cloud Services Console. Created site object will be available in Secure Mesh Site section of the F5 Distributed Cloud Services Console. Video-based description of the deployment Scenario This demonstration video shows the procedure for provisioning the deployment topology described above in three steps. References https://docs.cloud.f5.com/docs-v2/platform/services/mesh/secure-networking https://docs.cloud.f5.com/docs-v2/platform/concepts/site https://docs.cloud.f5.com/docs-v2/multi-cloud-network-connect/how-to/site-management https://docs.cloud.f5.com/docs-v2/multi-cloud-network-connect/how-to/site-management/deploy-aws-site-terraform https://docs.cloud.f5.com/docs-v2/multi-cloud-network-connect/troubleshooting/troubleshoot-manual-ce-deployment-registration-issues
C__Klewar
Jul 08, 2024 Place Technical Articles
189Views
0likes
0Comments
Integrate BIG-IP with AWS CloudWAN Service Insertion
AWS Cloud WAN is being adopted by many organizations and it is critical to secure traffic that traverses this service. By using F5 security solutions with AWS Cloud WAN service insertion you can enjoy the networking benefits of AWS Cloud WAN while providing the security, control and visibility your organization requires.
Heath_Parrott
Jun 11, 2024 Place Technical Articles
211Views
0likes
0Comments
F5 High Availability - Public Cloud Guidance
This article will provide information about BIG-IP and NGINX high availability (HA) topics that should be considered when leveraging the public cloud. There are differences between on-prem and public cloud such as cloud provider L2 networking. These differences lead to challenges in how you address HA, failover time, peer setup, scaling options, and application state. Topics Covered: Discuss and Define HA Importance of Application Behavior and Traffic Sizing HA Capabilities of BIG-IP and NGINX Various HA Deployment Options (Active/Active, Active/Standby, auto scale) Example Customer Scenario What is High Availability? High availability can mean many things to different people. Depending on the application and traffic requirements, HA requires dual data paths, redundant storage, redundant power, and compute. It means the ability to survive a failure, maintenance windows should be seamless to user, and the user experience should never suffer...ever! Reference: https://en.wikipedia.org/wiki/High_availability So what should HA provide? Synchronization of configuration data to peers (ex. configs objects) Synchronization of application session state (ex. persistence records) Enable traffic to fail over to a peer Locally, allow clusters of devices to act and appear as one unit Globally, disburse traffic via DNS and routing Importance of Application Behavior and Traffic Sizing Let's look at a common use case... "gaming app, lots of persistent connections, client needs to hit same backend throughout entire game session" Session State The requirement of session state is common across applications using methods like HTTP cookies, F5 iRule persistence, JSessionID, IP affinity, or hash. The session type used by the application can help you decide what migration path is right for you. Is this an app more fitting for a lift-n-shift approach...Rehost? Can the app be redesigned to take advantage of all native IaaS and PaaS technologies...Refactor? Reference: 6 R's of a Cloud Migration Application session state allows user to have a consistent and reliable experience Auto scaling L7 proxies (BIG-IP or NGINX) keep track of session state BIG-IP can only mirror session state to next device in cluster NGINX can mirror state to all devices in cluster (via zone sync) Traffic Sizing The cloud provider does a great job with things like scaling, but there are still cloud provider limits that affect sizing and machine instance types to keep in mind. BIG-IP and NGINX are considered network virtual appliances (NVA). They carry quota limits like other cloud objects. Google GCP VPC Resource Limits Azure VM Flow Limits AWS Instance Types Unfortunately, not all limits are documented. Key metrics for L7 proxies are typically SSL stats, throughput, connection type, and connection count. Collecting these application and traffic metrics can help identify the correct instance type. We have a list of the F5 supported BIG-IP VE platforms on F5 CloudDocs. F5 Products and HA Capabilities BIG-IP HA Capabilities BIG-IP supports the following HA cluster configurations: Active/Active - all devices processing traffic Active/Standby - one device processes traffic, others wait in standby Configuration sync to all devices in cluster L3/L4 connection sharing to next device in cluster (ex. avoids re-login) L5-L7 state sharing to next device in cluster (ex. IP persistence, SSL persistence, iRule UIE persistence) Reference: BIG-IP High Availability Docs NGINX HA Capabilities NGINX supports the following HA cluster configurations: Active/Active - all devices processing traffic Active/Standby - one device processes traffic, others wait in standby Configuration sync to all devices in cluster Mirroring connections at L3/L4 not available Mirroring session state to ALL devices in cluster using Zone Synchronization Module (NGINX Plus R15) Reference: NGINX High Availability Docs HA Methods for BIG-IP In the following sections, I will illustrate 3 common deployment configurations for BIG-IP in public cloud. HA for BIG-IP Design #1 - Active/Standby via API HA for BIG-IP Design #2 - A/A or A/S via LB HA for BIG-IP Design #3 - Regional Failover (multi region) HA for BIG-IP Design #1 - Active/Standby via API (multi AZ) This failover method uses API calls to communicate with the cloud provider and move objects (IP address, routes, etc) during failover events. The F5 Cloud Failover Extension (CFE) for BIG-IP is used to declaratively configure the HA settings. Cloud provider load balancer is NOT required Fail over time can be SLOW! Only one device actively used (other device sits idle) Failover uses API calls to move cloud objects, times vary (see CFE Performance and Sizing) Key Findings: Google API failover times depend on number of forwarding rules Azure API slow to disassociate/associate IPs to NICs (remapping) Azure API fast when updating routes (UDR, user defined routes) AWS reliable with API regarding IP moves and routes Recommendations: This design with multi AZ is more preferred than single AZ Recommend when "traditional" HA cluster required or Lift-n-Shift...Rehost For Azure (based on my testing)... Recommend using Azure UDR versus IP failover when possible Look at Failover via LB example instead for Azure If API method required, look at DNS solutions to provide further redundancy HA for BIG-IP Design #2 - A/A or A/S via LB (multi AZ) Cloud LB health checks the BIG-IP for up/down status Faster failover times (depends on cloud LB health timers) Cloud LB allows A/A or A/S Key difference: Increased network/compute redundancy Cloud load balancer required Recommendations: Use "failover via LB" if you require faster failover times For Google (based on my testing)... Recommend against "via LB" for IPSEC traffic (Google LB not supported) If load balancing IPSEC, then use "via API" or "via DNS" failover methods HA for BIG-IP Design #3 - Regional Failover via DNS (multi AZ, multi region) BIG-IP VE active/active in multiple regions Traffic disbursed to VEs by DNS/GSLB DNS/GSLB intelligent health checks for the VEs Key difference: Cloud LB is not required DNS logic required by clients Orchestration required to manage configs across each BIG-IP BIG-IP standalone devices (no DSC cluster limitations) Recommendations: Good for apps that handle DNS resolution well upon failover events Recommend when cloud LB cannot handle a particular protocol Recommend when customer is already using DNS to direct traffic Recommend for applications that have been refactored to handle session state outside of BIG-IP Recommend for customers with in-house skillset to orchestrate (Ansible, Terraform, etc) HA Methods for NGINX In the following sections, I will illustrate 2 common deployment configurations for NGINX in public cloud. HA for NGINX Design #1 - Active/Standby via API HA for NGINX Design #2 - Auto Scale Active/Active via LB HA for NGINX Design #1 - Active/Standby via API (multi AZ) NGINX Plus required Cloud provider load balancer is NOT required Only one device actively used (other device sits idle) Only available in AWS currently Recommendations: Recommend when "traditional" HA cluster required or Lift-n-Shift...Rehost Reference: Active-Passive HA for NGINX Plus on AWS HA for NGINX Design #2 - Auto Scale Active/Active via LB (multi AZ) NGINX Plus required Cloud LB health checks the NGINX Faster failover times Key difference: Increased network/compute redundancy Cloud load balancer required Recommendations: Recommended for apps fitting a migration type of Replatform or Refactor Reference: Active-Active HA for NGINX Plus on AWS, Active-Active HA for NGINX Plus on Google Pros & Cons: Public Cloud Scaling Options Review this handy table to understand the high level pros and cons of each deployment method. Example Customer Scenario #1 As a means to make this topic a little more real, here is a common customer scenario that shows you the decisions that go into moving an application to the public cloud. Sometimes it's as easy as a lift-n-shift, other times you might need to do a little more work. In general, public cloud is not on-prem and things might need some tweaking. Hopefully this example will give you some pointers and guidance on your next app migration to the cloud. Current Setup: Gaming applications F5 Hardware BIG-IP VIRPIONs on-prem Two data centers for HA redundancy iRule heavy configuration (TLS encryption/decryption, payload inspections) Session Persistence = iRule Universal Persistence (UIE), and other methods Biggest app 15K SSL TPS 15Gbps throughput 2 million concurrent connections 300K HTTP req/sec (L7 with TLS) Requirements for Successful Cloud Migration: Support current traffic numbers Support future target traffic growth Must run in multiple geographic regions Maintain session state Must retain all iRules in use Recommended Design for Cloud Phase #1: Migration Type: Hybrid model, on-prem + cloud, and some Rehost Platform: BIG-IP Retaining iRules means BIG-IP is required Licensing: High Performance BIG-IP Unlocks additional CPU cores past 8 (up to 24) extra traffic and SSL processing Instance type: check F5 supported BIG-IP VE platforms for accelerated networking (10Gb+) HA method: Active/Standby and multi-region with DNS iRule Universal persistence only mirrors to only next device, keep cluster size to 2 scale horizontally via additional HA clusters and DNS clients pinned to a region via DNS (on-prem or public cloud) inside region, local proxy cluster shares state This example comes up in customer conversations often. Based on customer requirements, in-house skillset, current operational model, and time frames there is one option that is better than the rest. A second design phase lends itself to more of a Replatform or Refactor migration type. In that case, more options can be leveraged to take advantage of cloud-native features. For example, changing the application persistence type from iRule UIE to cookie would allow BIG-IP to avoid keeping track of state. Why? With cookies, the client keeps track of that session state. Client receives a cookie, passes the cookie to L7 proxy on successive requests, proxy checks cookie value, sends to backend pool member. The requirement for L7 proxy to share session state is now removed. Example Customer Scenario #2 Here is another customer scenario. This time the application is a full suite of multimedia content. In contrast to the first scenario, this one will illustrate the benefits of rearchitecting various components allowing greater flexibility when leveraging the cloud. You still must factor in-house skill set, project time frames, and other important business (and application) requirements when deciding on the best migration type. Current Setup: Multimedia (Gaming, Movie, TV, Music) Platform BIG-IP VIPRIONs using vCMP on-prem Two data centers for HA redundancy iRule heavy (Security, Traffic Manipulation, Performance) Biggest App: oAuth + Cassandra for token storage (entitlements) Requirements for Success Cloud Migration: Support current traffic numbers Elastic auto scale for seasonal growth (ex. holidays) VPC peering with partners (must also bypass Web Application Firewall) Must support current or similar traffic manipulating in data plane Compatibility with existing tooling used by Business Recommended Design for Cloud Phase #1: Migration Type: Repurchase, migration BIG-IP to NGINX Plus Platform: NGINX iRules converted to JS or LUA Licensing: NGINX Plus Modules: GeoIP, LUA, JavaScript HA method: N+1 Autoscaling via Native LB Active Health Checks This is a great example of a Repurchase in which application characteristics can allow the various teams to explore alternative cloud migration approaches. In this scenario, it describes a phase one migration of converting BIG-IP devices to NGINX Plus devices. This example assumes the BIG-IP configurations can be somewhat easily converted to NGINX Plus, and it also assumes there is available skillset and project time allocated to properly rearchitect the application where needed. Summary OK! Brains are expanding...hopefully? We learned about high availability and what that means for applications and user experience. We touched on the importance of application behavior and traffic sizing. Then we explored the various F5 products, how they handle HA, and HA designs. These recommendations are based on my own lab testing and interactions with customers. Every scenario will carry its own requirements, and all options should be carefully considered when leveraging the public cloud. Finally, we looked at a customer scenario, discussed requirements, and design proposal. Fun! Resources Read the following articles for more guidance specific to the various cloud providers. Advanced Topologies and More on Highly Available Services Lightboard Lessons - BIG-IP Deployments in Azure Google and BIG-IP Failing Faster in the Cloud BIG-IP VE on Public Cloud High-Availability Load Balancing with NGINX Plus on Google Cloud Platform Using AWS Quick Starts to Deploy NGINX Plus NGINX on Azure
Jeff_Giroux_F5
Mar 19, 2024 Place Technical Articles
5.8KViews
5likes
2Comments
Building an OpenSSL Certificate Authority - Creating Your Root Certificate
Creating Your Root Certificate Authority In our previous article, Introductions and Design Considerations for Eliptical Curves we covered the design requirements to create a two-tier ECC certificate authority based on NSA Suite B's PKI requirements. We can now begin creating our CA's root configuration. Creating the root CA requires us to generate a certificate and private key, since this is the first certificate we're creating, it will be self-signed. The root CA will not sign client and server certificates, it's job it only to create intermeidary certificates and act as the root of our chain of trust. This is standard practice across the public and private PKI configurations and so too should your lab environments. Create Your Directory Structure Create a directory to store your root CA pair and config files. # sudo bash # mkdir /root/ca Yep, I did that. This is for a test lab and permissions may not match real world requirements. I sudoed into bash and created everything under root; aka playing with fire. This affects ownership down the line if you chmod private key files and directories to user access only so determine for yourself what user/permission will be accessing files for certificate creation. I have a small team and trust them with root within a lab environment (snapshots allow me to be this trusting). Create your CA database to keep track of signed certificates # cd /root/ca # mkdir private certs crl # touch index.txt # echo 1000 > serial We begin by creating a working root directory with sub directories for the various files we'll be creating. This will allow you to apply your preferred security practices should you choose to do so. Since this is a test lab and I am operating as root, I won't be chmod'ing anything today. Create Your OpenSSL Config File OpenSSL uses configuration files to simplify/template the components of a certificate. Copy the GIST openssl_root.cnf file to /root/ca/openssl_root.cnf which is already prepared for this demo. For the root CA certificate creation, the [ CA ] section is required and will gather it's configuration from the [ CA_default ] section. [ ca ] # `man ca` default_ca = CA_default The [CA_default] section in the openssl_root.cnf file contains the variables OpenSSL will use for the root CA. If you're using alternate directory names from this demo, update the file accordingly. Note the long values for default days (10 years) as we don't care about renewing the root certificate anytime soon. [ CA_default ] # Directory and file locations. dir = /root/ca certs = $dir/certs crl_dir = $dir/crl new_certs_dir = $dir/certs database = $dir/index.txt serial = $dir/serial RANDFILE = $dir/private/.rand # The root key and root certificate. private_key = $dir/private/ca.cheese.key.pem certificate = $dir/certs/ca.cheese.crt.pem # For certificate revocation lists. crlnumber = $dir/crlnumber crl = $dir/crl/ca.cheese.crl.pem crl_extensions = crl_ext default_crl_days = 3650 # SHA-1 is deprecated, so use SHA-2 or SHA-3 instead. default_md = sha384 name_opt = ca_default cert_opt = ca_default default_days = 3650 preserve = no policy = policy_strict For the root CA, we define [policy_strict] which will later force the intermediary's certificate to match country, state/province, and organization name fields. [ policy_strict ] The root CA should only sign intermediate certificates that match. # See POLICY FORMAT section of `man ca`. countryName = match stateOrProvinceName = match organizationName = match organizationalUnitName = optional commonName = supplied emailAddress = optional The [ req ] section is used for OpenSSL certificate requests. Some of the values listed will not be used since we are manually specifying them during certificate creation. [ req ] # Options for the `req` tool (`man req`). default_bits = 4096 distinguished_name = req_distinguished_name string_mask = utf8only # SHA-1 is deprecated, please use SHA-2 or greater instead. default_md = sha384 # Extension to add when the -x509 option is used. x509_extensions = v3_ca I pre-populate the [ req_distinguished_name ] section with values I'll commonly used to save typing down the road. [ req_distinguished_name ] countryName = Country Name (2 letter code) stateOrProvinceName = State or Province Name localityName = Locality Name 0.organizationName = Organization Name organizationalUnitName = Organizational Unit Name commonName = Common Name emailAddress = Email Address # Optionally, specify some defaults. countryName_default = US stateOrProvinceName_default = WA localityName_default = Seattle 0.organizationName_default = Grilled Cheese Inc. organizationalUnitName_default = Grilled Cheese Root CA emailAddress_default = grilledcheese@yummyinmytummy.us The [ v3_ca ] section will further define the Suite B PKI requirements, namely basicConstraints and acceptable keyUsage values for a CA certificate. This section will be used for creating the root CA's certificate. [ v3_ca ] # Extensions for a typical CA (`man x509v3_config`). subjectKeyIdentifier = hash authorityKeyIdentifier = keyid:always,issuer basicConstraints = critical, CA:true keyUsage = critical, digitalSignature, cRLSign, keyCertSign Selecting the Suite B compliant elliptical curve We're creating a Suite B infrastructure so we'll need to pick an acceptable curve following P-256 or P-384. To do this, run the following OpenSSL command: openssl ecparam -list_curves This will give you a long list of options but which one to pick? Let's isolate the suites within the 256 & 384 prime fields; we can grep the results for easier curve identification. openssl ecparam -list_curves | grep '256\|384' And we get the following results (your results may vary depending on the version of OpenSSL running): # openssl ecparam -list_curves | grep '256\|384' secp256k1 : SECG curve over a 256 bit prime field secp384r1 : NIST/SECG curve over a 384 bit prime field prime256v1: X9.62/SECG curve over a 256 bit prime field brainpoolP256r1: RFC 5639 curve over a 256 bit prime field brainpoolP256t1: RFC 5639 curve over a 256 bit prime field brainpoolP384r1: RFC 5639 curve over a 384 bit prime field brainpoolP384t1: RFC 5639 curve over a 384 bit prime field I am going to use secp384r1 as my curve of choice. It's good to mention that RFC5480 notes secp256r1 (not listed) is referred to as prime256v1 for this output's purpose. Why not use something larger than 384? Thank Google. People absolutely were using secp521r1 then Google dropped support for it (read Chromium Bug 478225 for more). The theory is since NSA Suite B PKI did not explicitly call out anything besides 256 or 384, the Chromium team quietly decided it wasn't needed and dropped support for it. Yea... it kinda annoyed a few people. So to avoid future browser issues, we're sticking with what's defined in public standards. Create the Root CA's Private Key Using the names defined in the openssl_root.cnf's private_key value and our selected secp384r1 ECC curve we will create and encrypt the root certificates private key. # openssl ecparam -genkey -name secp384r1 | openssl ec -aes256 -out private/ca.cheese.key.pem read EC key writing EC key Enter PEM pass phrase: ****** Verifying - Enter PEM pass phrase: ****** Note:The ecparam function within OpenSSL does not encrypt the private key like genrsa/gendsa/gendh does. Instead we combined the private key creation (openssl ecparam) with a secondary encryption command (openssl ec) to encrypt private key before it is written to disk. Keep the password safe. Create the Root CA's Certificate Using the new private key, we can now generate our root's self-signed certificate. We do this because the root has no authority above it to request trust authority from; it is the absolute source of authority in our certificate chain. # openssl req -config openssl_root.cnf -new -x509 -sha384 -extensions v3_ca -key private/ca.cheese.key.pem -out certs/ca.cheese.crt.pem Enter pass phrase for private/ca.cheese.key.pem: ****** You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter '.', the field will be left blank. ----- Country Name (2 letter code) [US]: State or Province Name [WA]: Locality Name [Seattle]: Organization Name [Grilled Cheese Inc.]: Organizational Unit Name [Grilled Cheese Root CA]: Common Name []:Grilled Cheese Root Certificate Authority Email Address [grilledcheese@yummyinmytummy.us]: Using OpenSSL we can validate the Certificate contents to ensure we're following the NSA Suite B requirements. # openssl x509 -noout -text -in certs/ca.cheese.crt.pem Certificate: Data: Version: 3 (0x2) Serial Number: ff:bd:f5:2f:c5:0d:3d:02 Signature Algorithm: ecdsa-with-SHA384 Issuer: C = US, ST = WA, L = Seattle, O = Grilled Cheese Inc., OU = Grilled Cheese Root CA, CN = Grilled Cheese Inc. Root Certificate Authority, emailAddress = grilledcheese@yummyinmytummy.us Validity Not Before: Aug 22 23:53:05 2017 GMT Not After : Aug 20 23:53:05 2027 GMT Subject: C = US, ST = WA, L = Seattle, O = Grilled Cheese Inc., OU = Grilled Cheese Root CA, CN = Grilled Cheese Inc. Root Certificate Authority, emailAddress = grilledcheese@yummyinmytummy.us Subject Public Key Info: Public Key Algorithm: id-ecPublicKey Public-Key: (384 bit) pub: 04:a6:b7:eb:8b:9f:fc:95:03:02:20:ea:64:7f:13: ea:b7:75:9b:cd:5e:43:ca:19:70:17:e2:0a:26:79: 0a:23:2f:20:de:02:2d:7c:8f:62:6b:74:7d:82:fe: 04:08:38:77:b7:8c:e0:e4:2b:27:0f:47:01:64:38: cb:15:a8:71:43:b2:d9:ff:ea:0e:d1:c8:f4:8f:99: d3:8e:2b:c1:90:d6:77:ab:0b:31:dd:78:d3:ce:96: b1:a0:c0:1c:b0:31:39 ASN1 OID: secp384r1 NIST CURVE: P-384 X509v3 extensions: X509v3 Subject Key Identifier: 27:C8:F7:34:2F:30:81:97:DE:2E:FC:DD:E2:1D:FD:B6:8F:5A:AF:BB X509v3 Authority Key Identifier: keyid:27:C8:F7:34:2F:30:81:97:DE:2E:FC:DD:E2:1D:FD:B6:8F:5A:AF:BB X509v3 Basic Constraints: critical CA:TRUE X509v3 Key Usage: critical Digital Signature, Certificate Sign, CRL Sign Signature Algorithm: ecdsa-with-SHA384 30:65:02:30:77:a1:f9:e2:ab:3a:5a:4b:ce:8d:6a:2e:30:3f: 01:cf:8e:76:dd:f6:1f:03:d9:b3:5c:a1:3d:6d:36:04:fb:01: f7:33:27:03:85:de:24:56:17:c9:1a:e4:3b:35:c4:a8:02:31: 00:cd:0e:6c:e0:d5:26:d3:fb:88:56:fa:67:9f:e9:be:b4:8f: 94:1c:2c:b7:74:19:ce:ec:15:d2:fe:48:93:0a:5f:ff:eb:b2: d3:ae:5a:68:87:dc:c9:2c:54:8d:04:68:7f Reviewing the above we can verify the certificate details: The Suite B Signature Algorithm: ecdsa-with-SHA384 The certificate date validity when we specificed -days 3650: Not Before: Aug 22 23:53:05 2017 GMT Not After : Aug 20 23:53:05 2027 GMT The Public-Key bit length: (384 bit) The Issuer we defined in the openssl_root.cnf: C = US, ST = WA, L = Seattle, O = Grilled Cheese Inc., OU = Grilled Cheese Root CA, CN = Grilled Cheese Inc. Root Certificate Authority The Certificate Subject, since this is self-signed, refers back to itself: Subject: C = US, ST = WA, L = Seattle, O = Grilled Cheese Inc., OU = Grilled Cheese Root CA, CN = Grilled Cheese Inc. Root Certificate Authority The eliptical curve used when we created the private key: NIST CURVE: P-384 Verify the X.509 v3 extensions we defined within the openssl_root.cnf for a Suite B CA use: X509v3 Basic Constraints: critical CA:TRUE X509v3 Key Usage: critical Digital Signature, Certificate Sign, CRL Sign The root certificate and private key are now compete and we have the first part of our CA complete. Step 1 complete! In our next article we will create the intermediary certificate to complete the chain of trust in our two-tier hierarchy.
Chase_Abbott
Jan 17, 2024 Place Technical Articles
17KViews
0likes
8Comments
Building an OpenSSL Certificate Authority - Creating Your Intermediary Certificate
Creating Your Intermediary Certificate Authority Previously we created the first part of our OpenSSL CA by building our root certificate. We are now ready to complete our CA chain by creating and signing the intermediary certificate. The intermediary will be responsible for signing client and server certificate requests. It acts as an authoritative proxy for the root certificate hence the name intermediary. The chain of trust will extend from the root certificate to the intermediary certificate down to the certificates you'll deploy within your infrastructure. Create your directory structure Create a new subdirectory under /root/ca to segregate intermediary files our root configuration . # sudo bash # mkdir /root/ca/intermediate We're creating the same directory structure previously used under /root/ca within /root/ca/intermediary . It's your decision if you if you want to do something different. Some of my best friends are flat directory structures and we don't judge personal practices. Create your intermediary CA database to keep track of signed certificates # cd /root/ca/intermediate # mkdir certs crl csr private # touch index.txt # echo 1000 > serial Create a crlnumber file for the intermediary CA to use # echo 1000 > /root/ca/intermediate/crlnumber Similar to the earlier serial statement, this will create the crlnumber file and start the numerical iteration at 1000. This will be used for future certificate revocation needs. Create your OpenSSL intermediary config file Copy the GIST openssl_intermediate.cnf file to /root/ca/intermediate/openssl_intermediate.cnf and modify the contents for your own naming conventions. Similar to the root_ca.cnf , the [CA] is required and will gather it's configuration from the [CA_default] section. Changes to the [int_ca] include: [ CA_default ] # Directory and file locations. dir = /root/ca/intermediate private_key = $dir/private/int.cheese.key.pem certificate = $dir/cers/int.cheese.crt.pem crlnumber = $dir/crlnumber crl = $dir/crl/int.cheese.crl.pem crl_extensions = crl_ext policy = policy_loose We have new certificate names for our intermediary use and define policy_loose so future certificate requests don't have to match country, state/province, or organization. Create the Intermediary's Private Key and Certificate Signing Request Similar to the root certificate, we're following the NSA Suite B requirements and matching the root's elliptical curve, secp384r1. We'll also create the CSR and private key all in one line, making your scripts and life a bit easier. # cd /root/ca # openssl req -config intermediate/openssl_intermediate.cnf -new -newkey ec:<(openssl ecparam -name secp384r1) -keyout intermediate/private/int.cheese.key.pem -out intermediate/csr/int.cheese.csr Generating an EC private key writing new private key to 'intermediate/private/int.cheese.key.pem' Enter PEM pass phrase: ****** Verifying - Enter PEM pass phrase: ****** ----- You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter '.', the field will be left blank. ----- Country Name (2 letter code) [US]: State or Province Name [WA]: Locality Name [Seattle]: Organization Name [Grilled Cheese Inc.]: Organizational Unit Name [Grilled Cheese Intermediary CA]: Common Name []:Grilled Cheese Inc. Intermediary Certificate Authority Email Address [grilledcheese@yummyinmytummy.us]: Sign the certificate request with the root certificate and use the openssl_intermediate.cnf config file to specify the [v3_intermediate_ca] extension instead of the [v3_ca] as we did for the root. The openssl_intermediate.cnf has a few changes which we need to note. [ v3_intermediate_ca ] # Extensions for a typical intermediate CA (`man x509v3_config`). subjectKeyIdentifier = hash authorityKeyIdentifier = keyid:always,issuer basicConstraints = critical, CA:true, pathlen:0 keyUsage = critical, digitalSignature, cRLSign, keyCertSign crlDistributionPoints = @crl_info authorityInfoAccess = @ocsp_info [crl_info] URI.0 = http://crl.grilledcheese.us/whoremovedmycheese.crl [ocsp_info] caIssuers;URI.0 = http://ocsp.grilledcheese.us/cheddarcheeseroot.crt OCSP;URI.0 = http://ocsp.grilledcheese.us/ The Certificate Revocation List (crl) and Online Certificate Status Protocol (OCSP) should be included within the intermediary certificate. This lets systems know where check and see if the intermediary certificate was revoked by the root at any given time. We will cover this in detail later and browsers do not necessarily check the intermediary certificates for revocation, but they absolutely do for the site certificates. We're adding CRL and OCSP to the Intermediary CA for best practices purpose. Create the intermediate certificate Sign the csr/int.cheese.cs r with the root's certificate. We are going to drop down to /root/ca so the creation of the intermediary certificate is stored within the root's index.txt and we'll also use the root's OpenSSL Config file openssl_root.cnf . # openssl ca -config openssl_root.cnf -extensions v3_intermediate_ca -days 3600 -md sha384 -in intermediate/csr/int.cheese.csr -out intermediate/certs/int.cheese.crt.pem Using configuration from openssl_root.cnf Enter pass phrase for /root/ca/private/ca.cheese.key.pem: Check that the request matches the signature Signature ok Certificate Details: Serial Number: 4097 (0x1001) Validity Not Before: Aug 24 21:51:07 2017 GMT Not After : Jul 3 21:51:07 2027 GMT Subject: countryName = US stateOrProvinceName = WA organizationName = Grilled Cheese Inc. organizationalUnitName = Grilled Cheese Intermediary CA commonName = Grilled Cheese Inc. Intermediary Certificate Authority emailAddress = grilledcheese@yummyinmytummy.us X509v3 extensions: X509v3 Subject Key Identifier: 7E:2D:A5:D0:9B:70:B9:E3:D2:F7:C0:0A:CF:70:9A:8B:80:38:B1:CD X509v3 Authority Key Identifier: keyid:27:C8:F7:34:2F:30:81:97:DE:2E:FC:DD:E2:1D:FD:B6:8F:5A:AF:BB X509v3 Basic Constraints: critical CA:TRUE, pathlen:0 X509v3 Key Usage: critical Digital Signature, Certificate Sign, CRL Sign X509v3 CRL Distribution Points: Full Name: URI:http://crl.grilledcheese.us/whomovedmycheese.crl Authority Information Access: CA Issuers - URI:http://ocsp.grilledcheese.us/cheddarcheeseroot.crt OCSP - URI:http://ocsp.grilledcheese.us/ Certificate is to be certified until Jul 3 21:51:07 2027 GMT (3600 days) Sign the certificate? [y/n]:y 1 out of 1 certificate requests certified, commit? [y/n]y Write out database with 1 new entries Data Base Updated Validate the Certificate Contents with OpenSSL. # openssl x509 -noout -text -in intermediate/certs/int.cheese.crt.pem Certificate: Data: Version: 3 (0x2) Serial Number: 4097 (0x1001) Signature Algorithm: ecdsa-with-SHA384 Issuer: C = US, ST = WA, L = Seattle, O = Grilled Cheese Inc., OU = Grilled Cheese Root CA, CN = Grilled Cheese Inc. Root Certificate Authority, emailAddress = grilledcheese@yummyinmytummy.us Validity Not Before: Aug 24 21:51:07 2017 GMT Not After : Jul 3 21:51:07 2027 GMT Subject: C = US, ST = WA, O = Grilled Cheese Inc., OU = Grilled Cheese Intermediary CA, CN = Grilled Cheese Inc. Intermediary Certificate Authority, emailAddress = grilledcheese@yummyinmytummy.us Subject Public Key Info: Public Key Algorithm: id-ecPublicKey Public-Key: (384 bit) pub: 04:9b:14:9a:55:6d:db:15:7f:d7:8b:fd:37:4d:ba: e8:50:8e:88:32:99:27:4e:20:36:25:8b:7b:ac:bb: 2f:d6:61:c1:5a:c8:e6:4c:98:20:3f:cf:86:3c:bf: f4:f3:b0:1c:1c:0b:cc:7f:e4:4b:13:59:58:a1:53: 87:cb:4c:17:66:04:21:01:6a:44:5f:22:31:7d:3d: fe:a2:e7:73:c8:77:7c:1a:f9:9c:4a:9d:e7:77:6a: c7:9e:3e:f0:4a:b0:37 ASN1 OID: secp384r1 NIST CURVE: P-384 X509v3 extensions: X509v3 Subject Key Identifier: 7E:2D:A5:D0:9B:70:B9:E3:D2:F7:C0:0A:CF:70:9A:8B:80:38:B1:CD X509v3 Authority Key Identifier: keyid:27:C8:F7:34:2F:30:81:97:DE:2E:FC:DD:E2:1D:FD:B6:8F:5A:AF:BB X509v3 Basic Constraints: critical CA:TRUE, pathlen:0 X509v3 Key Usage: critical Digital Signature, Certificate Sign, CRL Sign X509v3 CRL Distribution Points: Full Name: URI:http://crl.grilledcheese.us/whomovedmycheese.crl Authority Information Access: CA Issuers - URI:http://ocsp.grilledcheese.us/cheddarcheeseroot.crt OCSP - URI:http://ocsp.grilledcheese.us/ Signature Algorithm: ecdsa-with-SHA384 30:65:02:30:74:07:ba:fe:4b:71:78:d8:d2:7f:84:c0:50:b4: b6:df:6c:f6:57:f5:d9:2c:4b:e1:d4:d8:1d:78:fd:7e:bf:0a: 81:86:bb:40:c5:9b:97:6f:83:04:5f:d3:85:36:6c:d6:02:31: 00:d3:08:78:1c:da:6d:ef:1d:bb:27:df:0b:76:eb:ab:84:b2: 91:04:25:1a:85:5b:d5:c3:cd:66:e4:9e:14:b2:c0:ed:9c:59: b7:18:c3:26:eb:df:78:13:68:47:66:b5:43 Similar to the root, we can note the usage and algorithms but we have the addition of: * X509v3 CRL Distribution Points: Full Name: URI:http://crl.grilledcheese.us/whomovedmycheese.crl *Authority Information Access: CA Issuers - URI:http://ocsp.grilledcheese.us/cheddarcheeseroot.crt OCSP - URI:http://ocsp.grilledcheese.us/ Create the certificate chain The root certificate and intermediary certificate must be available to the requesting client/server in order to validate the chain of trust. To complete the trust validation, a certificate chain must be available to the client application. A certificate chain usually takes the form of separate certificates installed into Root and Intermediary containers (as the case for Windows), or bundled together either in a .pfx cert and cert chain bundle or a PEM formatted text file. Concatenate the root and intermediate certificates together to create a PEM certificate chain text file. # cd /root/ca # $cat intermediate/certs/int.cheese.crt.pem certs/ca.cheese.crt.pem > intermediate/certs/chain.cheese.crt.pem The file should look similar to this with two separate BEGIN and END statements for each certificate (example condensed for space): # cat intermediate/certs/chain.cheese.crt.pem -----BEGIN CERTIFICATE----- MIID/TCCA4OgAwIBAgICEAEwCgYIKoZIzj0EAwMwgdQxCzAJBgNVBAYTAlVTMQsw CQYDVQQIDAJXQTEQMA4GA1UEBwwHU2VhdHRsZTEcMBoGA1UECgwTR3JpbGxlZCBD ...... hkjOPQQDAwNoADBlAjB0B7r+S3F42NJ/hMBQtLbfbPZX9dksS+HU2B14/X6/CoGG u0DFm5dvgwRf04U2bNYCMQDTCHgc2m3vHbsn3wt266uEspEEJRqFW9XDzWbknhSy wO2cWbcYwybr33gTaEdmtUM= -----END CERTIFICATE----- -----BEGIN CERTIFICATE----- MIIDQTCCAsegAwIBAgIJAP+99S/FDT0CMAoGCCqGSM49BAMDMIHUMQswCQYDVQQG EwJVUzELMAkGA1UECAwCV0ExEDAOBgNVBAcMB1NlYXR0bGUxHDAaBgNVBAoME0dy ...... CgYIKoZIzj0EAwMDaAAwZQIwd6H54qs6WkvOjWouMD8Bz4523fYfA9mzXKE9bTYE +wH3MycDhd4kVhfJGuQ7NcSoAjEAzQ5s4NUm0/uIVvpnn+m+tI+UHCy3dBnO7BXS /kiTCl//67LTrlpoh9zJLFSNBGh/ -----END CERTIFICATE----- Note: In the real world hosting application should never have the entire chain available as it defeats a core principle of PKI. It's recommended in test labs to distribute the root certificate to all testing client applications and systems and include only the intermediary along with the server certificate. This way the client can establish the trust between the intermediary and root certificates. Next we'll move on to creating our CLR endpoint list and OCSP certificate. Our intermediary certificate is now created and signed and we are ready to move on. To complete the CA our next article we will create our certificate revocation list (CRL) endpoint and online certificate status protocol (OCSP) certificate allowing us to revoke certificates. Lab environments rarely need revocation functionality but modern clients check for CLR and OCSP URIs so it's nessisary to have the configruation defined at minimum. Let's proceed.
Chase_Abbott
Jan 17, 2024 Place Technical Articles
11KViews
0likes
2Comments
Ingress/Egress VPC inspection with BIG-IP and GWLB
Introduction The previous article in this series reviewed the BIG-IP and AWS Gateway Load Balancer (GWLB) integration, in this article we will focus on a deployment pattern that is used to inspect traffic in and out of a VPC using BIG-IP security services and GWLB. Baseline: In this scenario we will focus on a single existing VPC with EC2 instances and no BIG-IP security services Goal: Inspect traffic in and out of the VPC, scale the BIG-IP deployment as needed Deployment pattern: Considering the requirements and tools available, the deployment pattern will use the following attributes: Separate the security devices (BIG-IP's) from the workloads they are protecting. The BIG-IP's will be deployed in their own VPC – the Security VPC. We will reference the workload VPC as the 'Consumer' VPC as it consumes security services. Use Routing tables in the 'consumer' VPC to send all traffic to the security VPC for inspection. Leverage transparent security services on the BIG-IP for inspection (BIG-IP security features configuration is out of scope for this article) We can dive into each of the individual tasks: The Security VPC Provisioning the 'consumer' VPC network to send traffic through the security VPC Security VPC: Here, we are deploying the BIG-IP fleet and exposing it using GWLB. Some of the considerations when creating this VPC: Deploy in the same region as the 'consumer' VPC Design based on your availability requirements, Number of availability zones(AZ) How many BIG-IP's in each AZ These are the actions we need to take in the provider VPC to inspect all ingress/egress traffic: Deploy a group of BIG-IP's Create a GWLB target group and associate the BIG-IP's to it Create a GWLB and assign the previously created target group to the listener Create a GWLB endpoint service and associate it with the GWLB Configure the BIG-IP's to receive traffic over the tunnel and inspect according to the desired policy Diagram: The security VPC - BIG-IP fleet behind a GWLB, exposed using GWLB service Consumer VPC: In the consumer VPC, the BIG-IP group is abstracted by the GWLB and consumes the security services from the provider VPC via a new component: GWLB endpoint. This endpoint acts as bridge between the consumer VPC and the provider VPC. It essentially creates an ENI in one of the consumer's VPC subnet. Please note that a single endpoint belongs to a single availability zone and design accordingly. Inspecting all ingress traffic requires the use of 'Ingress routing' – an AWS feature that allows sending all ingress traffic from the internet gateway to an ENI or to a GWLB endpoint. Here are the actions we need to take in the consumer VPC to inspect all ingress/egress traffic: Create GWLB endpoints in each relevant availability zone that are attached to the 'GWLB endpoint service' from the provider VPC Change the ingress routing table so that all traffic in each AZ will get routed to the respective GWLB endpoint. Change the subnets routing tables so that all traffic in each AZ will get routed to the respective GWLB endpoint. Diagram: Inspecting all ingress/egress in the Security provider VPC Traffic flow Ingress traffic flow between an external user and an EC2 instance in the consumer VPC: Egress traffic flow between an EC2 instance in the consumer VPC and an external user: Summary: With this deployment you can protect your AWS VPC using the robust security services offered by the BIG-IP platform and get the following benefits: Scalability - Deploy as many BIG-IP instances as you need based on performance and availability requirements Transparent inspection - Inspecting the traffic without any address translation Optimized compute - all BIG-IP devices are active and processing traffic Next steps: Test the deployment yourself - Check out our self-service lab that you can deploy in your own AWS account (Fully automated deployment using Terraform): https://github.com/f5devcentral/f5-digital-customer-engagement-center/tree/main/solutions/security/ingress-egress-fw
Yossi_Rosenboi1
Nov 21, 2023 Place Technical Articles
1.6KViews
2likes
1Comment
Deploy BIG-IP in AWS with HA across AZ’s - without using EIP’s
Background: The CloudFormation templates that are provided and supported by F5 are an excellent resource for customers to deploy BIG-IP VE in AWS. Along with these templates, documentation guiding your F5 deployment in AWS is an excellent resource. And of course, DevCentral articles are helpful. I recommend reading about HA topologies in AWS to start. I hope my article today can shed more light on an architecture that will suit a specific set of requirements: No Elastic IP's (EIP’s), High Availability (HA) across AZ’s, and multiple VPC’s. Requirements behind this architecture choice: I recently had a requirement to deploy BIG-IP appliances in AWS across AZ’s. I had read the official deployment guide, but I wasn’t clear on how to achieve failover without EIP’s. I was given 3 requirements: HA across AZ’s. In this architecture, we required a pair of BIG-IP devices in Active/Standby, where each device was in a different AZ. I needed to be able to fail over between devices. No EIP’s. This requirement existed because a 3 rd party firewall was already exposed to the Internet with a public IP address. That firewall would forward inbound requests to the BIG-IP VE in AWS, which in turn proxied traffic to a pair of web servers. Therefore, there was no reason to associate an EIP (a public IP address) with the BIG-IP interface. In my demo below I have not exposed a public website through a 3 rd party firewall, but to do so is a simple addition to this demo environment. Multiple VPC’s. This architecture had to allow for multiple VPC’s in AWS. There was already a “Security VPC” which contained firewalls, BIG-IP devices, and other devices, and I had to be able to use these devices for protecting applications that were across 1 or more disparate VPC’s. Meeting the requirements: HA across AZ’s This is the easiest of the requirements to meet because F5 has already provided templates to deploy these in AWS. I personally used a 2-nic device, with a BYOL license, deployed to an existing VPC, so that meant my template was this one. After this deployment is complete, you should have a pair of devices that will sync their configuration. At time of failover The supported F5 templates will deploy with the Advanced HA iApp. It is important that you configure this iApp after you have completed your AWS deployments. The iApp uses IAM permissions deployed with the template to make API calls to AWS at the time of failover. The API calls will update the route tables that you specify within the iApp wizard. Because this iApp is installed on both devices, either device can update the route in your route tables to point to its own interface. Update as of Dec 2019 This article was first written Feb 2019, and in Dec 2019 F5 released the Cloud Failover Extension (CFE), which is a cloud-agnostic, declarative way to configure failover in multiple public clouds. You can use the CFE instead of the Advanced HA iApp to achieve high availability between BIG-IP devices in cloud. Update as of Apr 2020 Your API calls will typically be sent to the public Internet endpoints for AWS EC2 API calls. Optionally, you can use AWS VPC endpoints to keep your API calls out to AWS EC2 from traversing the public Internet. My colleague Arnulfo Hernandez has written an article explaining how to do this. No EIP’s Configure an “alien IP range” I’m recycling another DevCentral solution here. You will need to choose an IP range for your VIP network that does not fall within the CIDR that is assigned to your VPC. Let’s call it an “alien range” because it “doesn’t belong” in your VPC and you couldn’t assign IP addresses from this range to your AWS ENI’s. Despite that, now create a route table within AWS that points this “alien range” to your Active BIG-IP device’s ENI (if you’re using a 2+ nic device, point it to the correct data plane NIC, not the Mgmt. interface). Don’t forget to associate the route table with specific subnets, per your design. Alternatively, you could add this route to the default VPC route table. Create a VIP on your active device Now create a VIP on your active device and configure the IP address as an IP within your alien range. Ensure the config replicates to your standby device. Ensure that source/destination checking is disabled on the ENI’s that your AWS routes are pointing to (on both Standby and Active devices). You should now have a VIP that you can target from other hosts in your VPC, provided that the route you created above is applied to the traffic destined to the VIP. Multiple VPC’s For extra credit, we’ll set up a Transit Gateway. This will allow other VPCs to route traffic to this “alien range” also, provided that the appropriate routes exist in the remote VPC’s, and also are applied to the appropriate Transit Gateway Route Table. Again, I’m recycling ideas that have already been laid out in other DevCentral posts. I won’t re-hash how to set up a transit gateway in AWS, because you can follow the linked post above. Sufficed to say, this is what you will need to set up if you want to route between multiple VPC’s using a transit gateway: 2 or more VPC’s A transit gateway in AWS Multiple transit gateway attachments that attach the transit gateway and each VPC you would like to route between. You will need one attachment per VPC. A transit gateway route table that is associated with each attachment. I will point out that you need to add a route for your “alien range” in your transit gateway route table, and in your remote VPC’s. That way, hosts in your remote VPC’s will forward traffic destined to your alien range (VIP network) to the transit gateway, and the transit gateway will forward it to your VPC, and the route you created in Step A will forward that traffic to your active BIG-IP device. Completed design: After the above configuration, you should have an environment that looks like the diagram below: Tips Internet access for deployments: When you deploy your BIG-IP devices, they will need Internet access to pull down some resources, including the iApp. So if you are deploying devices into your existing VPC, make sure you have a reachable Internet Gateway in AWS so that the devices have Internet access through both their management interface, and their data plane interface(s). Internet access for failover: Remember that an API call to AWS will still use an outbound request to the Internet. Make sure you allow the BIG-IP devices to make outbound connections over HTTPS to the Internet. If this is not available, you will find that your route tables are not updated at time of failover. (If you have a hard requirement that your devices should not have outbound access to internet, you can follow Arnulfo's guide linked to above and use VPC endpoints to keep this traffic on your local VPC) iApp logs: you can enable this in the iApp settings. I have used the logs (in /var/ltm/log) to troubleshoot issues that I have created myself. That’s how I learned not to accidentally cut off Internet access for your devices! Don’t forget about return routes if SNAT is disabled: Just like on-prem environments, if you disable SNAT, the pool member will need to route return traffic back to the BIG-IP device. You will commonly set up a default route (0.0.0.0/0) in AWS, point it at the ENI of the active BIG-IP device, and associate this route table with the subnet containing the pool members. If the pool members are in a remote VPC, you will need to create this route on the transit gw route table also. Don’t accidentally cut off internet access: When you configure the default route of 0.0.0.0/0 to point to eth1 of the BIG-IP device, don’t apply this route to every subnet in your Security VPC. It may be easy to do so accidentally, but remember that it could cause the API calls to update route tables to fail when the Standby device becomes Active. Don’t forget to disable source/dest check on your ENI’s. This is configured by the template, but if you have other devices that require it, remember to check this setting.
MichaelOLeary
Sep 07, 2023 Place Technical Articles
8.4KViews
5likes
27Comments
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!
ChrisMutzel_151
Jul 24, 2023 Place Technical Articles
1.4KViews
1like
3Comments

"}},"componentScriptGroups({\"componentId\":\"custom.widget.Beta_MetaNav\"})":{"__typename":"ComponentScriptGroups","scriptGroups":{"__typename":"ComponentScriptGroupsDefinition","afterInteractive":{"__typename":"PageScriptGroupDefinition","group":"AFTER_INTERACTIVE","scriptIds":[]},"lazyOnLoad":{"__typename":"PageScriptGroupDefinition","group":"LAZY_ON_LOAD","scriptIds":[]}},"componentScripts":[]},"component({\"componentId\":\"custom.widget.Beta_Footer\"})":{"__typename":"Component","render({\"context\":{\"component\":{\"entities\":[],\"props\":{}},\"page\":{\"entities\":[],\"name\":\"TagPage\",\"props\":{},\"url\":\"https://community.f5.com/tag/AWS\"}}})":{"__typename":"ComponentRenderResult","html":"

Trademarks Policies Privacy California Privacy Do Not Sell My Personal Information

"}},"componentScriptGroups({\"componentId\":\"custom.widget.Beta_Footer\"})":{"__typename":"ComponentScriptGroups","scriptGroups":{"__typename":"ComponentScriptGroupsDefinition","afterInteractive":{"__typename":"PageScriptGroupDefinition","group":"AFTER_INTERACTIVE","scriptIds":[]},"lazyOnLoad":{"__typename":"PageScriptGroupDefinition","group":"LAZY_ON_LOAD","scriptIds":[]}},"componentScripts":[]},"component({\"componentId\":\"custom.widget.Tag_Manager_Helper\"})":{"__typename":"Component","render({\"context\":{\"component\":{\"entities\":[],\"props\":{}},\"page\":{\"entities\":[],\"name\":\"TagPage\",\"props\":{},\"url\":\"https://community.f5.com/tag/AWS\"}}})":{"__typename":"ComponentRenderResult","html":" "}},"componentScriptGroups({\"componentId\":\"custom.widget.Tag_Manager_Helper\"})":{"__typename":"ComponentScriptGroups","scriptGroups":{"__typename":"ComponentScriptGroupsDefinition","afterInteractive":{"__typename":"PageScriptGroupDefinition","group":"AFTER_INTERACTIVE","scriptIds":[]},"lazyOnLoad":{"__typename":"PageScriptGroupDefinition","group":"LAZY_ON_LOAD","scriptIds":[]}},"componentScripts":[]},"component({\"componentId\":\"custom.widget.Consent_Blackbar\"})":{"__typename":"Component","render({\"context\":{\"component\":{\"entities\":[],\"props\":{}},\"page\":{\"entities\":[],\"name\":\"TagPage\",\"props\":{},\"url\":\"https://community.f5.com/tag/AWS\"}}})":{"__typename":"ComponentRenderResult","html":"

"}},"componentScriptGroups({\"componentId\":\"custom.widget.Consent_Blackbar\"})":{"__typename":"ComponentScriptGroups","scriptGroups":{"__typename":"ComponentScriptGroupsDefinition","afterInteractive":{"__typename":"PageScriptGroupDefinition","group":"AFTER_INTERACTIVE","scriptIds":[]},"lazyOnLoad":{"__typename":"PageScriptGroupDefinition","group":"LAZY_ON_LOAD","scriptIds":[]}},"componentScripts":[]},"cachedText({\"lastModified\":\"1744046279002\",\"locale\":\"en-US\",\"namespaces\":[\"components/community/NavbarDropdownToggle\"]})":[{"__ref":"CachedAsset:text:en_US-components/community/NavbarDropdownToggle-1744046279002"}],"cachedText({\"lastModified\":\"1744046279002\",\"locale\":\"en-US\",\"namespaces\":[\"shared/client/components/common/OverflowNav\"]})":[{"__ref":"CachedAsset:text:en_US-shared/client/components/common/OverflowNav-1744046279002"}],"cachedText({\"lastModified\":\"1744046279002\",\"locale\":\"en-US\",\"namespaces\":[\"components/messages/MessageView/MessageViewInline\"]})":[{"__ref":"CachedAsset:text:en_US-components/messages/MessageView/MessageViewInline-1744046279002"}],"cachedText({\"lastModified\":\"1744046279002\",\"locale\":\"en-US\",\"namespaces\":[\"shared/client/components/common/Pager/PagerLoadMore\"]})":[{"__ref":"CachedAsset:text:en_US-shared/client/components/common/Pager/PagerLoadMore-1744046279002"}],"cachedText({\"lastModified\":\"1744046279002\",\"locale\":\"en-US\",\"namespaces\":[\"components/customComponent/CustomComponent\"]})":[{"__ref":"CachedAsset:text:en_US-components/customComponent/CustomComponent-1744046279002"}],"cachedText({\"lastModified\":\"1744046279002\",\"locale\":\"en-US\",\"namespaces\":[\"components/users/UserLink\"]})":[{"__ref":"CachedAsset:text:en_US-components/users/UserLink-1744046279002"}],"cachedText({\"lastModified\":\"1744046279002\",\"locale\":\"en-US\",\"namespaces\":[\"components/messages/MessageSubject\"]})":[{"__ref":"CachedAsset:text:en_US-components/messages/MessageSubject-1744046279002"}],"cachedText({\"lastModified\":\"1744046279002\",\"locale\":\"en-US\",\"namespaces\":[\"components/messages/MessageTime\"]})":[{"__ref":"CachedAsset:text:en_US-components/messages/MessageTime-1744046279002"}],"cachedText({\"lastModified\":\"1744046279002\",\"locale\":\"en-US\",\"namespaces\":[\"shared/client/components/nodes/NodeIcon\"]})":[{"__ref":"CachedAsset:text:en_US-shared/client/components/nodes/NodeIcon-1744046279002"}],"cachedText({\"lastModified\":\"1744046279002\",\"locale\":\"en-US\",\"namespaces\":[\"components/messages/MessageUnreadCount\"]})":[{"__ref":"CachedAsset:text:en_US-components/messages/MessageUnreadCount-1744046279002"}],"cachedText({\"lastModified\":\"1744046279002\",\"locale\":\"en-US\",\"namespaces\":[\"components/messages/MessageViewCount\"]})":[{"__ref":"CachedAsset:text:en_US-components/messages/MessageViewCount-1744046279002"}],"cachedText({\"lastModified\":\"1744046279002\",\"locale\":\"en-US\",\"namespaces\":[\"components/kudos/KudosCount\"]})":[{"__ref":"CachedAsset:text:en_US-components/kudos/KudosCount-1744046279002"}],"cachedText({\"lastModified\":\"1744046279002\",\"locale\":\"en-US\",\"namespaces\":[\"components/messages/MessageRepliesCount\"]})":[{"__ref":"CachedAsset:text:en_US-components/messages/MessageRepliesCount-1744046279002"}],"cachedText({\"lastModified\":\"1744046279002\",\"locale\":\"en-US\",\"namespaces\":[\"components/messages/MessageBody\"]})":[{"__ref":"CachedAsset:text:en_US-components/messages/MessageBody-1744046279002"}],"cachedText({\"lastModified\":\"1744046279002\",\"locale\":\"en-US\",\"namespaces\":[\"shared/client/components/users/UserAvatar\"]})":[{"__ref":"CachedAsset:text:en_US-shared/client/components/users/UserAvatar-1744046279002"}]},"CachedAsset:pages-1743756125778":{"__typename":"CachedAsset","id":"pages-1743756125778","value":[{"lastUpdatedTime":1743756125778,"localOverride":null,"page":{"id":"HowDoI.GetInvolved.MvpProgram","type":"COMMUNITY","urlPath":"/c/how-do-i/get-involved/mvp-program","__typename":"PageDescriptor"},"__typename":"PageResource"},{"lastUpdatedTime":1743756125778,"localOverride":null,"page":{"id":"BlogViewAllPostsPage","type":"BLOG","urlPath":"/category/:categoryId/blog/:boardId/all-posts/(/:after|/:before)?","__typename":"PageDescriptor"},"__typename":"PageResource"},{"lastUpdatedTime":1743756125778,"localOverride":null,"page":{"id":"CasePortalPage","type":"CASE_PORTAL","urlPath":"/caseportal","__typename":"PageDescriptor"},"__typename":"PageResource"},{"lastUpdatedTime":1743756125778,"localOverride":null,"page":{"id":"CreateGroupHubPage","type":"GROUP_HUB","urlPath":"/groups/create","__typename":"PageDescriptor"},"__typename":"PageResource"},{"lastUpdatedTime":1743756125778,"localOverride":null,"page":{"id":"CaseViewPage","type":"CASE_DETAILS","urlPath":"/case/:caseId/:caseNumber","__typename":"PageDescriptor"},"__typename":"PageResource"},{"lastUpdatedTime":1743756125778,"localOverride":null,"page":{"id":"InboxPage","type":"COMMUNITY","urlPath":"/inbox","__typename":"PageDescriptor"},"__typename":"PageResource"},{"lastUpdatedTime":1743756125778,"localOverride":null,"page":{"id":"HowDoI.GetInvolved.AdvocacyProgram","type":"COMMUNITY","urlPath":"/c/how-do-i/get-involved/advocacy-program","__typename":"PageDescriptor"},"__typename":"PageResource"},{"lastUpdatedTime":1743756125778,"localOverride":null,"page":{"id":"HowDoI.GetHelp.NonCustomer","type":"COMMUNITY","urlPath":"/c/how-do-i/get-help/non-customer","__typename":"PageDescriptor"},"__typename":"PageResource"},{"lastUpdatedTime":1743756125778,"localOverride":null,"page":{"id":"HelpFAQPage","type":"COMMUNITY","urlPath":"/help","__typename":"PageDescriptor"},"__typename":"PageResource"},{"lastUpdatedTime":1743756125778,"localOverride":null,"page":{"id":"HowDoI.GetHelp.F5Customer","type":"COMMUNITY","urlPath":"/c/how-do-i/get-help/f5-customer","__typename":"PageDescriptor"},"__typename":"PageResource"},{"lastUpdatedTime":1743756125778,"localOverride":null,"page":{"id":"IdeaMessagePage","type":"IDEA_POST","urlPath":"/idea/:boardId/:messageSubject/:messageId","__typename":"PageDescriptor"},"__typename":"PageResource"},{"lastUpdatedTime":1743756125778,"localOverride":null,"page":{"id":"IdeaViewAllIdeasPage","type":"IDEA","urlPath":"/category/:categoryId/ideas/:boardId/all-ideas/(/:after|/:before)?","__typename":"PageDescriptor"},"__typename":"PageResource"},{"lastUpdatedTime":1743756125778,"localOverride":null,"page":{"id":"LoginPage","type":"USER","urlPath":"/signin","__typename":"PageDescriptor"},"__typename":"PageResource"},{"lastUpdatedTime":1743756125778,"localOverride":null,"page":{"id":"BlogPostPage","type":"BLOG","urlPath":"/category/:categoryId/blogs/:boardId/create","__typename":"PageDescriptor"},"__typename":"PageResource"},{"lastUpdatedTime":1743756125778,"localOverride":null,"page":{"id":"HowDoI.GetInvolved","type":"COMMUNITY","urlPath":"/c/how-do-i/get-involved","__typename":"PageDescriptor"},"__typename":"PageResource"},{"lastUpdatedTime":1743756125778,"localOverride":null,"page":{"id":"HowDoI.Learn","type":"COMMUNITY","urlPath":"/c/how-do-i/learn","__typename":"PageDescriptor"},"__typename":"PageResource"},{"lastUpdatedTime":1739501996000,"localOverride":null,"page":{"id":"Test","type":"CUSTOM","urlPath":"/custom-test-2","__typename":"PageDescriptor"},"__typename":"PageResource"},{"lastUpdatedTime":1743756125778,"localOverride":null,"page":{"id":"ThemeEditorPage","type":"COMMUNITY","urlPath":"/designer/themes","__typename":"PageDescriptor"},"__typename":"PageResource"},{"lastUpdatedTime":1743756125778,"localOverride":null,"page":{"id":"TkbViewAllArticlesPage","type":"TKB","urlPath":"/category/:categoryId/kb/:boardId/all-articles/(/:after|/:before)?","__typename":"PageDescriptor"},"__typename":"PageResource"},{"lastUpdatedTime":1743756125778,"localOverride":null,"page":{"id":"OccasionEditPage","type":"EVENT","urlPath":"/event/:boardId/:messageSubject/:messageId/edit","__typename":"PageDescriptor"},"__typename":"PageResource"},{"lastUpdatedTime":1743756125778,"localOverride":null,"page":{"id":"OAuthAuthorizationAllowPage","type":"USER","urlPath":"/auth/authorize/allow","__typename":"PageDescriptor"},"__typename":"PageResource"},{"lastUpdatedTime":1743756125778,"localOverride":null,"page":{"id":"PageEditorPage","type":"COMMUNITY","urlPath":"/designer/pages","__typename":"PageDescriptor"},"__typename":"PageResource"},{"lastUpdatedTime":1743756125778,"localOverride":null,"page":{"id":"PostPage","type":"COMMUNITY","urlPath":"/category/:categoryId/:boardId/create","__typename":"PageDescriptor"},"__typename":"PageResource"},{"lastUpdatedTime":1743756125778,"localOverride":null,"page":{"id":"ForumBoardPage","type":"FORUM","urlPath":"/category/:categoryId/discussions/:boardId","__typename":"PageDescriptor"},"__typename":"PageResource"},{"lastUpdatedTime":1743756125778,"localOverride":null,"page":{"id":"TkbBoardPage","type":"TKB","urlPath":"/category/:categoryId/kb/:boardId","__typename":"PageDescriptor"},"__typename":"PageResource"},{"lastUpdatedTime":1743756125778,"localOverride":null,"page":{"id":"EventPostPage","type":"EVENT","urlPath":"/category/:categoryId/events/:boardId/create","__typename":"PageDescriptor"},"__typename":"PageResource"},{"lastUpdatedTime":1743756125778,"localOverride":null,"page":{"id":"UserBadgesPage","type":"COMMUNITY","urlPath":"/users/:login/:userId/badges","__typename":"PageDescriptor"},"__typename":"PageResource"},{"lastUpdatedTime":1743756125778,"localOverride":null,"page":{"id":"GroupHubMembershipAction","type":"GROUP_HUB","urlPath":"/membership/join/:nodeId/:membershipType","__typename":"PageDescriptor"},"__typename":"PageResource"},{"lastUpdatedTime":1743756125778,"localOverride":null,"page":{"id":"MaintenancePage","type":"COMMUNITY","urlPath":"/maintenance","__typename":"PageDescriptor"},"__typename":"PageResource"},{"lastUpdatedTime":1743756125778,"localOverride":null,"page":{"id":"IdeaReplyPage","type":"IDEA_REPLY","urlPath":"/idea/:boardId/:messageSubject/:messageId/comments/:replyId","__typename":"PageDescriptor"},"__typename":"PageResource"},{"lastUpdatedTime":1743756125778,"localOverride":null,"page":{"id":"UserSettingsPage","type":"USER","urlPath":"/mysettings/:userSettingsTab","__typename":"PageDescriptor"},"__typename":"PageResource"},{"lastUpdatedTime":1743756125778,"localOverride":null,"page":{"id":"GroupHubsPage","type":"GROUP_HUB","urlPath":"/groups","__typename":"PageDescriptor"},"__typename":"PageResource"},{"lastUpdatedTime":1743756125778,"localOverride":null,"page":{"id":"ForumPostPage","type":"FORUM","urlPath":"/category/:categoryId/discussions/:boardId/create","__typename":"PageDescriptor"},"__typename":"PageResource"},{"lastUpdatedTime":1743756125778,"localOverride":null,"page":{"id":"OccasionRsvpActionPage","type":"OCCASION","urlPath":"/event/:boardId/:messageSubject/:messageId/rsvp/:responseType","__typename":"PageDescriptor"},"__typename":"PageResource"},{"lastUpdatedTime":1743756125778,"localOverride":null,"page":{"id":"VerifyUserEmailPage","type":"USER","urlPath":"/verifyemail/:userId/:verifyEmailToken","__typename":"PageDescriptor"},"__typename":"PageResource"},{"lastUpdatedTime":1743756125778,"localOverride":null,"page":{"id":"AllOccasionsPage","type":"OCCASION","urlPath":"/category/:categoryId/events/:boardId/all-events/(/:after|/:before)?","__typename":"PageDescriptor"},"__typename":"PageResource"},{"lastUpdatedTime":1743756125778,"localOverride":null,"page":{"id":"EventBoardPage","type":"EVENT","urlPath":"/category/:categoryId/events/:boardId","__typename":"PageDescriptor"},"__typename":"PageResource"},{"lastUpdatedTime":1743756125778,"localOverride":null,"page":{"id":"TkbReplyPage","type":"TKB_REPLY","urlPath":"/kb/:boardId/:messageSubject/:messageId/comments/:replyId","__typename":"PageDescriptor"},"__typename":"PageResource"},{"lastUpdatedTime":1743756125778,"localOverride":null,"page":{"id":"IdeaBoardPage","type":"IDEA","urlPath":"/category/:categoryId/ideas/:boardId","__typename":"PageDescriptor"},"__typename":"PageResource"},{"lastUpdatedTime":1743756125778,"localOverride":null,"page":{"id":"CommunityGuideLinesPage","type":"COMMUNITY","urlPath":"/communityguidelines","__typename":"PageDescriptor"},"__typename":"PageResource"},{"lastUpdatedTime":1743756125778,"localOverride":null,"page":{"id":"CaseCreatePage","type":"SALESFORCE_CASE_CREATION","urlPath":"/caseportal/create","__typename":"PageDescriptor"},"__typename":"PageResource"},{"lastUpdatedTime":1743756125778,"localOverride":null,"page":{"id":"TkbEditPage","type":"TKB","urlPath":"/kb/:boardId/:messageSubject/:messageId/edit","__typename":"PageDescriptor"},"__typename":"PageResource"},{"lastUpdatedTime":1743756125778,"localOverride":null,"page":{"id":"ForgotPasswordPage","type":"USER","urlPath":"/forgotpassword","__typename":"PageDescriptor"},"__typename":"PageResource"},{"lastUpdatedTime":1743756125778,"localOverride":null,"page":{"id":"IdeaEditPage","type":"IDEA","urlPath":"/idea/:boardId/:messageSubject/:messageId/edit","__typename":"PageDescriptor"},"__typename":"PageResource"},{"lastUpdatedTime":1743756125778,"localOverride":null,"page":{"id":"TagPage","type":"COMMUNITY","urlPath":"/tag/:tagName","__typename":"PageDescriptor"},"__typename":"PageResource"},{"lastUpdatedTime":1743756125778,"localOverride":null,"page":{"id":"BlogBoardPage","type":"BLOG","urlPath":"/category/:categoryId/blog/:boardId","__typename":"PageDescriptor"},"__typename":"PageResource"},{"lastUpdatedTime":1743756125778,"localOverride":null,"page":{"id":"OccasionMessagePage","type":"OCCASION_TOPIC","urlPath":"/event/:boardId/:messageSubject/:messageId","__typename":"PageDescriptor"},"__typename":"PageResource"},{"lastUpdatedTime":1743756125778,"localOverride":null,"page":{"id":"ManageContentPage","type":"COMMUNITY","urlPath":"/managecontent","__typename":"PageDescriptor"},"__typename":"PageResource"},{"lastUpdatedTime":1743756125778,"localOverride":null,"page":{"id":"ClosedMembershipNodeNonMembersPage","type":"GROUP_HUB","urlPath":"/closedgroup/:groupHubId","__typename":"PageDescriptor"},"__typename":"PageResource"},{"lastUpdatedTime":1743756125778,"localOverride":null,"page":{"id":"HowDoI.GetHelp.Community","type":"COMMUNITY","urlPath":"/c/how-do-i/get-help/community","__typename":"PageDescriptor"},"__typename":"PageResource"},{"lastUpdatedTime":1743756125778,"localOverride":null,"page":{"id":"CommunityPage","type":"COMMUNITY","urlPath":"/","__typename":"PageDescriptor"},"__typename":"PageResource"},{"lastUpdatedTime":1743756125778,"localOverride":null,"page":{"id":"HowDoI.GetInvolved.ContributeCode","type":"COMMUNITY","urlPath":"/c/how-do-i/get-involved/contribute-code","__typename":"PageDescriptor"},"__typename":"PageResource"},{"lastUpdatedTime":1743756125778,"localOverride":null,"page":{"id":"ForumMessagePage","type":"FORUM_TOPIC","urlPath":"/discussions/:boardId/:messageSubject/:messageId","__typename":"PageDescriptor"},"__typename":"PageResource"},{"lastUpdatedTime":1743756125778,"localOverride":null,"page":{"id":"IdeaPostPage","type":"IDEA","urlPath":"/category/:categoryId/ideas/:boardId/create","__typename":"PageDescriptor"},"__typename":"PageResource"},{"lastUpdatedTime":1743756125778,"localOverride":null,"page":{"id":"BlogMessagePage","type":"BLOG_ARTICLE","urlPath":"/blog/:boardId/:messageSubject/:messageId","__typename":"PageDescriptor"},"__typename":"PageResource"},{"lastUpdatedTime":1743756125778,"localOverride":null,"page":{"id":"RegistrationPage","type":"USER","urlPath":"/register","__typename":"PageDescriptor"},"__typename":"PageResource"},{"lastUpdatedTime":1743756125778,"localOverride":null,"page":{"id":"EditGroupHubPage","type":"GROUP_HUB","urlPath":"/group/:groupHubId/edit","__typename":"PageDescriptor"},"__typename":"PageResource"},{"lastUpdatedTime":1743756125778,"localOverride":null,"page":{"id":"ForumEditPage","type":"FORUM","urlPath":"/discussions/:boardId/:messageSubject/:messageId/edit","__typename":"PageDescriptor"},"__typename":"PageResource"},{"lastUpdatedTime":1743756125778,"localOverride":null,"page":{"id":"ResetPasswordPage","type":"USER","urlPath":"/resetpassword/:userId/:resetPasswordToken","__typename":"PageDescriptor"},"__typename":"PageResource"},{"lastUpdatedTime":1743756125778,"localOverride":null,"page":{"id":"TkbMessagePage","type":"TKB_ARTICLE","urlPath":"/kb/:boardId/:messageSubject/:messageId","__typename":"PageDescriptor"},"__typename":"PageResource"},{"lastUpdatedTime":1743756125778,"localOverride":null,"page":{"id":"HowDoI.Learn.AboutIrules","type":"COMMUNITY","urlPath":"/c/how-do-i/learn/about-irules","__typename":"PageDescriptor"},"__typename":"PageResource"},{"lastUpdatedTime":1743756125778,"localOverride":null,"page":{"id":"BlogEditPage","type":"BLOG","urlPath":"/blog/:boardId/:messageSubject/:messageId/edit","__typename":"PageDescriptor"},"__typename":"PageResource"},{"lastUpdatedTime":1743756125778,"localOverride":null,"page":{"id":"HowDoI.GetHelp.F5Support","type":"COMMUNITY","urlPath":"/c/how-do-i/get-help/f5-support","__typename":"PageDescriptor"},"__typename":"PageResource"},{"lastUpdatedTime":1743756125778,"localOverride":null,"page":{"id":"ManageUsersPage","type":"USER","urlPath":"/users/manage/:tab?/:manageUsersTab?","__typename":"PageDescriptor"},"__typename":"PageResource"},{"lastUpdatedTime":1743756125778,"localOverride":null,"page":{"id":"ForumReplyPage","type":"FORUM_REPLY","urlPath":"/discussions/:boardId/:messageSubject/:messageId/replies/:replyId","__typename":"PageDescriptor"},"__typename":"PageResource"},{"lastUpdatedTime":1743756125778,"localOverride":null,"page":{"id":"PrivacyPolicyPage","type":"COMMUNITY","urlPath":"/privacypolicy","__typename":"PageDescriptor"},"__typename":"PageResource"},{"lastUpdatedTime":1743756125778,"localOverride":null,"page":{"id":"NotificationPage","type":"COMMUNITY","urlPath":"/notifications","__typename":"PageDescriptor"},"__typename":"PageResource"},{"lastUpdatedTime":1743756125778,"localOverride":null,"page":{"id":"UserPage","type":"USER","urlPath":"/users/:login/:userId","__typename":"PageDescriptor"},"__typename":"PageResource"},{"lastUpdatedTime":1743756125778,"localOverride":null,"page":{"id":"HealthCheckPage","type":"COMMUNITY","urlPath":"/health","__typename":"PageDescriptor"},"__typename":"PageResource"},{"lastUpdatedTime":1743756125778,"localOverride":null,"page":{"id":"OccasionReplyPage","type":"OCCASION_REPLY","urlPath":"/event/:boardId/:messageSubject/:messageId/comments/:replyId","__typename":"PageDescriptor"},"__typename":"PageResource"},{"lastUpdatedTime":1743756125778,"localOverride":null,"page":{"id":"ManageMembersPage","type":"GROUP_HUB","urlPath":"/group/:groupHubId/manage/:tab?","__typename":"PageDescriptor"},"__typename":"PageResource"},{"lastUpdatedTime":1743756125778,"localOverride":null,"page":{"id":"SearchResultsPage","type":"COMMUNITY","urlPath":"/search","__typename":"PageDescriptor"},"__typename":"PageResource"},{"lastUpdatedTime":1743756125778,"localOverride":null,"page":{"id":"BlogReplyPage","type":"BLOG_REPLY","urlPath":"/blog/:boardId/:messageSubject/:messageId/replies/:replyId","__typename":"PageDescriptor"},"__typename":"PageResource"},{"lastUpdatedTime":1743756125778,"localOverride":null,"page":{"id":"GroupHubPage","type":"GROUP_HUB","urlPath":"/group/:groupHubId","__typename":"PageDescriptor"},"__typename":"PageResource"},{"lastUpdatedTime":1743756125778,"localOverride":null,"page":{"id":"TermsOfServicePage","type":"COMMUNITY","urlPath":"/termsofservice","__typename":"PageDescriptor"},"__typename":"PageResource"},{"lastUpdatedTime":1743756125778,"localOverride":null,"page":{"id":"HowDoI.GetHelp","type":"COMMUNITY","urlPath":"/c/how-do-i/get-help","__typename":"PageDescriptor"},"__typename":"PageResource"},{"lastUpdatedTime":1743756125778,"localOverride":null,"page":{"id":"HowDoI.GetHelp.SecurityIncident","type":"COMMUNITY","urlPath":"/c/how-do-i/get-help/security-incident","__typename":"PageDescriptor"},"__typename":"PageResource"},{"lastUpdatedTime":1743756125778,"localOverride":null,"page":{"id":"CategoryPage","type":"CATEGORY","urlPath":"/category/:categoryId","__typename":"PageDescriptor"},"__typename":"PageResource"},{"lastUpdatedTime":1743756125778,"localOverride":null,"page":{"id":"ForumViewAllTopicsPage","type":"FORUM","urlPath":"/category/:categoryId/discussions/:boardId/all-topics/(/:after|/:before)?","__typename":"PageDescriptor"},"__typename":"PageResource"},{"lastUpdatedTime":1743756125778,"localOverride":null,"page":{"id":"TkbPostPage","type":"TKB","urlPath":"/category/:categoryId/kbs/:boardId/create","__typename":"PageDescriptor"},"__typename":"PageResource"},{"lastUpdatedTime":1743756125778,"localOverride":null,"page":{"id":"GroupHubPostPage","type":"GROUP_HUB","urlPath":"/group/:groupHubId/:boardId/create","__typename":"PageDescriptor"},"__typename":"PageResource"},{"lastUpdatedTime":1743756125778,"localOverride":null,"page":{"id":"HowDoI","type":"COMMUNITY","urlPath":"/c/how-do-i","__typename":"PageDescriptor"},"__typename":"PageResource"}],"localOverride":false},"CachedAsset:text:en_US-components/context/AppContext/AppContextProvider-0":{"__typename":"CachedAsset","id":"text:en_US-components/context/AppContext/AppContextProvider-0","value":{"noCommunity":"Cannot find community","noUser":"Cannot find current user","noNode":"Cannot find node with id {nodeId}","noMessage":"Cannot find message with id {messageId}"},"localOverride":false},"CachedAsset:text:en_US-shared/client/components/common/Loading/LoadingDot-0":{"__typename":"CachedAsset","id":"text:en_US-shared/client/components/common/Loading/LoadingDot-0","value":{"title":"Loading..."},"localOverride":false},"User:user:-1":{"__typename":"User","id":"user:-1","uid":-1,"login":"Former Member","email":"","avatar":null,"rank":null,"kudosWeight":1,"registrationData":{"__typename":"RegistrationData","status":"ANONYMOUS","registrationTime":null,"confirmEmailStatus":false,"registrationAccessLevel":"VIEW","ssoRegistrationFields":[]},"ssoId":null,"profileSettings":{"__typename":"ProfileSettings","dateDisplayStyle":{"__typename":"InheritableStringSettingWithPossibleValues","key":"layout.friendly_dates_enabled","value":"false","localValue":"true","possibleValues":["true","false"]},"dateDisplayFormat":{"__typename":"InheritableStringSetting","key":"layout.format_pattern_date","value":"dd-MMM-yyyy","localValue":"MM-dd-yyyy"},"language":{"__typename":"InheritableStringSettingWithPossibleValues","key":"profile.language","value":"en-US","localValue":null,"possibleValues":["en-US"]}},"deleted":false},"Theme:customTheme1":{"__typename":"Theme","id":"customTheme1"},"CachedAsset:theme:customTheme1-1743756125333":{"__typename":"CachedAsset","id":"theme:customTheme1-1743756125333","value":{"id":"customTheme1","animation":{"fast":"150ms","normal":"250ms","slow":"500ms","slowest":"750ms","function":"cubic-bezier(0.07, 0.91, 0.51, 1)","__typename":"AnimationThemeSettings"},"avatar":{"borderRadius":"50%","collections":["custom"],"__typename":"AvatarThemeSettings"},"basics":{"browserIcon":{"imageAssetName":"JimmyPackets-512-1702592938213.png","imageLastModified":"1702592945815","__typename":"ThemeAsset"},"customerLogo":{"imageAssetName":"f5_logo_fix-1704824537976.svg","imageLastModified":"1704824540697","__typename":"ThemeAsset"},"maximumWidthOfPageContent":"1600px","oneColumnNarrowWidth":"800px","gridGutterWidthMd":"30px","gridGutterWidthXs":"10px","pageWidthStyle":"WIDTH_OF_PAGE_CONTENT","__typename":"BasicsThemeSettings"},"buttons":{"borderRadiusSm":"5px","borderRadius":"5px","borderRadiusLg":"5px","paddingY":"5px","paddingYLg":"7px","paddingYHero":"var(--lia-bs-btn-padding-y-lg)","paddingX":"12px","paddingXLg":"14px","paddingXHero":"42px","fontStyle":"NORMAL","fontWeight":"400","textTransform":"NONE","disabledOpacity":0.5,"primaryTextColor":"var(--lia-bs-white)","primaryTextHoverColor":"var(--lia-bs-white)","primaryTextActiveColor":"var(--lia-bs-white)","primaryBgColor":"var(--lia-bs-primary)","primaryBgHoverColor":"hsl(var(--lia-bs-primary-h), var(--lia-bs-primary-s), calc(var(--lia-bs-primary-l) * 0.85))","primaryBgActiveColor":"hsl(var(--lia-bs-primary-h), var(--lia-bs-primary-s), calc(var(--lia-bs-primary-l) * 0.7))","primaryBorder":"1px solid transparent","primaryBorderHover":"1px solid transparent","primaryBorderActive":"1px solid transparent","primaryBorderFocus":"1px solid var(--lia-bs-white)","primaryBoxShadowFocus":"0 0 0 1px var(--lia-bs-primary), 0 0 0 4px hsla(var(--lia-bs-primary-h), var(--lia-bs-primary-s), var(--lia-bs-primary-l), 0.2)","secondaryTextColor":"var(--lia-bs-gray-900)","secondaryTextHoverColor":"hsl(var(--lia-bs-gray-900-h), var(--lia-bs-gray-900-s), calc(var(--lia-bs-gray-900-l) * 0.95))","secondaryTextActiveColor":"hsl(var(--lia-bs-gray-900-h), var(--lia-bs-gray-900-s), calc(var(--lia-bs-gray-900-l) * 0.9))","secondaryBgColor":"var(--lia-bs-gray-400)","secondaryBgHoverColor":"hsl(var(--lia-bs-gray-400-h), var(--lia-bs-gray-400-s), calc(var(--lia-bs-gray-400-l) * 0.96))","secondaryBgActiveColor":"hsl(var(--lia-bs-gray-400-h), var(--lia-bs-gray-400-s), calc(var(--lia-bs-gray-400-l) * 0.92))","secondaryBorder":"1px solid transparent","secondaryBorderHover":"1px solid transparent","secondaryBorderActive":"1px solid transparent","secondaryBorderFocus":"1px solid transparent","secondaryBoxShadowFocus":"0 0 0 1px var(--lia-bs-primary), 0 0 0 4px hsla(var(--lia-bs-primary-h), var(--lia-bs-primary-s), var(--lia-bs-primary-l), 0.2)","tertiaryTextColor":"var(--lia-bs-gray-900)","tertiaryTextHoverColor":"hsl(var(--lia-bs-gray-900-h), var(--lia-bs-gray-900-s), calc(var(--lia-bs-gray-900-l) * 0.95))","tertiaryTextActiveColor":"hsl(var(--lia-bs-gray-900-h), var(--lia-bs-gray-900-s), calc(var(--lia-bs-gray-900-l) * 0.9))","tertiaryBgColor":"transparent","tertiaryBgHoverColor":"transparent","tertiaryBgActiveColor":"hsla(var(--lia-bs-black-h), var(--lia-bs-black-s), var(--lia-bs-black-l), 0.04)","tertiaryBorder":"1px solid transparent","tertiaryBorderHover":"1px solid hsla(var(--lia-bs-black-h), var(--lia-bs-black-s), var(--lia-bs-black-l), 0.08)","tertiaryBorderActive":"1px solid transparent","tertiaryBorderFocus":"1px solid transparent","tertiaryBoxShadowFocus":"0 0 0 1px var(--lia-bs-primary), 0 0 0 4px hsla(var(--lia-bs-primary-h), var(--lia-bs-primary-s), var(--lia-bs-primary-l), 0.2)","destructiveTextColor":"var(--lia-bs-danger)","destructiveTextHoverColor":"hsl(var(--lia-bs-danger-h), var(--lia-bs-danger-s), calc(var(--lia-bs-danger-l) * 0.95))","destructiveTextActiveColor":"hsl(var(--lia-bs-danger-h), var(--lia-bs-danger-s), calc(var(--lia-bs-danger-l) * 0.9))","destructiveBgColor":"var(--lia-bs-gray-300)","destructiveBgHoverColor":"hsl(var(--lia-bs-gray-300-h), var(--lia-bs-gray-300-s), calc(var(--lia-bs-gray-300-l) * 0.96))","destructiveBgActiveColor":"hsl(var(--lia-bs-gray-300-h), var(--lia-bs-gray-300-s), calc(var(--lia-bs-gray-300-l) * 0.92))","destructiveBorder":"1px solid transparent","destructiveBorderHover":"1px solid transparent","destructiveBorderActive":"1px solid transparent","destructiveBorderFocus":"1px solid transparent","destructiveBoxShadowFocus":"0 0 0 1px var(--lia-bs-primary), 0 0 0 4px hsla(var(--lia-bs-primary-h), var(--lia-bs-primary-s), var(--lia-bs-primary-l), 0.2)","__typename":"ButtonsThemeSettings"},"border":{"color":"hsla(var(--lia-bs-black-h), var(--lia-bs-black-s), var(--lia-bs-black-l), 0.08)","mainContent":"NONE","sideContent":"NONE","radiusSm":"3px","radius":"5px","radiusLg":"9px","radius50":"100vw","__typename":"BorderThemeSettings"},"boxShadow":{"xs":"0 0 0 1px hsla(var(--lia-bs-gray-900-h), var(--lia-bs-gray-900-s), var(--lia-bs-gray-900-l), 0.08), 0 3px 0 -1px hsla(var(--lia-bs-gray-900-h), var(--lia-bs-gray-900-s), var(--lia-bs-gray-900-l), 0.08)","sm":"0 2px 4px hsla(var(--lia-bs-gray-900-h), var(--lia-bs-gray-900-s), var(--lia-bs-gray-900-l), 0.06)","md":"0 5px 15px hsla(var(--lia-bs-gray-900-h), var(--lia-bs-gray-900-s), var(--lia-bs-gray-900-l), 0.15)","lg":"0 10px 30px hsla(var(--lia-bs-gray-900-h), var(--lia-bs-gray-900-s), var(--lia-bs-gray-900-l), 0.15)","__typename":"BoxShadowThemeSettings"},"cards":{"bgColor":"var(--lia-panel-bg-color)","borderRadius":"var(--lia-panel-border-radius)","boxShadow":"var(--lia-box-shadow-xs)","__typename":"CardsThemeSettings"},"chip":{"maxWidth":"300px","height":"30px","__typename":"ChipThemeSettings"},"coreTypes":{"defaultMessageLinkColor":"var(--lia-bs-primary)","defaultMessageLinkDecoration":"none","defaultMessageLinkFontStyle":"NORMAL","defaultMessageLinkFontWeight":"400","defaultMessageFontStyle":"NORMAL","defaultMessageFontWeight":"400","forumColor":"#0C5C8D","forumFontFamily":"var(--lia-bs-font-family-base)","forumFontWeight":"var(--lia-default-message-font-weight)","forumLineHeight":"var(--lia-bs-line-height-base)","forumFontStyle":"var(--lia-default-message-font-style)","forumMessageLinkColor":"var(--lia-default-message-link-color)","forumMessageLinkDecoration":"var(--lia-default-message-link-decoration)","forumMessageLinkFontStyle":"var(--lia-default-message-link-font-style)","forumMessageLinkFontWeight":"var(--lia-default-message-link-font-weight)","forumSolvedColor":"#62C026","blogColor":"#730015","blogFontFamily":"var(--lia-bs-font-family-base)","blogFontWeight":"var(--lia-default-message-font-weight)","blogLineHeight":"1.75","blogFontStyle":"var(--lia-default-message-font-style)","blogMessageLinkColor":"var(--lia-default-message-link-color)","blogMessageLinkDecoration":"var(--lia-default-message-link-decoration)","blogMessageLinkFontStyle":"var(--lia-default-message-link-font-style)","blogMessageLinkFontWeight":"var(--lia-default-message-link-font-weight)","tkbColor":"#C20025","tkbFontFamily":"var(--lia-bs-font-family-base)","tkbFontWeight":"var(--lia-default-message-font-weight)","tkbLineHeight":"1.75","tkbFontStyle":"var(--lia-default-message-font-style)","tkbMessageLinkColor":"var(--lia-default-message-link-color)","tkbMessageLinkDecoration":"var(--lia-default-message-link-decoration)","tkbMessageLinkFontStyle":"var(--lia-default-message-link-font-style)","tkbMessageLinkFontWeight":"var(--lia-default-message-link-font-weight)","qandaColor":"#4099E2","qandaFontFamily":"var(--lia-bs-font-family-base)","qandaFontWeight":"var(--lia-default-message-font-weight)","qandaLineHeight":"var(--lia-bs-line-height-base)","qandaFontStyle":"var(--lia-default-message-link-font-style)","qandaMessageLinkColor":"var(--lia-default-message-link-color)","qandaMessageLinkDecoration":"var(--lia-default-message-link-decoration)","qandaMessageLinkFontStyle":"var(--lia-default-message-link-font-style)","qandaMessageLinkFontWeight":"var(--lia-default-message-link-font-weight)","qandaSolvedColor":"#3FA023","ideaColor":"#F3704B","ideaFontFamily":"var(--lia-bs-font-family-base)","ideaFontWeight":"var(--lia-default-message-font-weight)","ideaLineHeight":"var(--lia-bs-line-height-base)","ideaFontStyle":"var(--lia-default-message-font-style)","ideaMessageLinkColor":"var(--lia-default-message-link-color)","ideaMessageLinkDecoration":"var(--lia-default-message-link-decoration)","ideaMessageLinkFontStyle":"var(--lia-default-message-link-font-style)","ideaMessageLinkFontWeight":"var(--lia-default-message-link-font-weight)","contestColor":"#FCC845","contestFontFamily":"var(--lia-bs-font-family-base)","contestFontWeight":"var(--lia-default-message-font-weight)","contestLineHeight":"var(--lia-bs-line-height-base)","contestFontStyle":"var(--lia-default-message-link-font-style)","contestMessageLinkColor":"var(--lia-default-message-link-color)","contestMessageLinkDecoration":"var(--lia-default-message-link-decoration)","contestMessageLinkFontStyle":"ITALIC","contestMessageLinkFontWeight":"var(--lia-default-message-link-font-weight)","occasionColor":"#EE4B5B","occasionFontFamily":"var(--lia-bs-font-family-base)","occasionFontWeight":"var(--lia-default-message-font-weight)","occasionLineHeight":"var(--lia-bs-line-height-base)","occasionFontStyle":"var(--lia-default-message-font-style)","occasionMessageLinkColor":"var(--lia-default-message-link-color)","occasionMessageLinkDecoration":"var(--lia-default-message-link-decoration)","occasionMessageLinkFontStyle":"var(--lia-default-message-link-font-style)","occasionMessageLinkFontWeight":"var(--lia-default-message-link-font-weight)","grouphubColor":"#491B62","categoryColor":"#949494","communityColor":"#FFFFFF","productColor":"#949494","__typename":"CoreTypesThemeSettings"},"colors":{"black":"#000000","white":"#FFFFFF","gray100":"#F7F7F7","gray200":"#F7F7F7","gray300":"#E8E8E8","gray400":"#D9D9D9","gray500":"#CCCCCC","gray600":"#949494","gray700":"#707070","gray800":"#545454","gray900":"#333333","dark":"#545454","light":"#F7F7F7","primary":"#0C5C8D","secondary":"#333333","bodyText":"#222222","bodyBg":"#F5F5F5","info":"#1D9CD3","success":"#62C026","warning":"#FFD651","danger":"#C20025","alertSystem":"#FF6600","textMuted":"#707070","highlight":"#FFFCAD","outline":"var(--lia-bs-primary)","custom":["#C20025","#081B85","#009639","#B3C6D7","#7CC0EB","#F29A36"],"__typename":"ColorsThemeSettings"},"divider":{"size":"3px","marginLeft":"4px","marginRight":"4px","borderRadius":"50%","bgColor":"var(--lia-bs-gray-600)","bgColorActive":"var(--lia-bs-gray-600)","__typename":"DividerThemeSettings"},"dropdown":{"fontSize":"var(--lia-bs-font-size-sm)","borderColor":"var(--lia-bs-border-color)","borderRadius":"var(--lia-bs-border-radius-sm)","dividerBg":"var(--lia-bs-gray-300)","itemPaddingY":"5px","itemPaddingX":"20px","headerColor":"var(--lia-bs-gray-700)","__typename":"DropdownThemeSettings"},"email":{"link":{"color":"#0069D4","hoverColor":"#0061c2","decoration":"none","hoverDecoration":"underline","__typename":"EmailLinkSettings"},"border":{"color":"#e4e4e4","__typename":"EmailBorderSettings"},"buttons":{"borderRadiusLg":"5px","paddingXLg":"16px","paddingYLg":"7px","fontWeight":"700","primaryTextColor":"#ffffff","primaryTextHoverColor":"#ffffff","primaryBgColor":"#0069D4","primaryBgHoverColor":"#005cb8","primaryBorder":"1px solid transparent","primaryBorderHover":"1px solid transparent","__typename":"EmailButtonsSettings"},"panel":{"borderRadius":"5px","borderColor":"#e4e4e4","__typename":"EmailPanelSettings"},"__typename":"EmailThemeSettings"},"emoji":{"skinToneDefault":"#ffcd43","skinToneLight":"#fae3c5","skinToneMediumLight":"#e2cfa5","skinToneMedium":"#daa478","skinToneMediumDark":"#a78058","skinToneDark":"#5e4d43","__typename":"EmojiThemeSettings"},"heading":{"color":"var(--lia-bs-body-color)","fontFamily":"Inter","fontStyle":"NORMAL","fontWeight":"600","h1FontSize":"30px","h2FontSize":"25px","h3FontSize":"20px","h4FontSize":"18px","h5FontSize":"16px","h6FontSize":"16px","lineHeight":"1.2","subHeaderFontSize":"11px","subHeaderFontWeight":"500","h1LetterSpacing":"normal","h2LetterSpacing":"normal","h3LetterSpacing":"normal","h4LetterSpacing":"normal","h5LetterSpacing":"normal","h6LetterSpacing":"normal","subHeaderLetterSpacing":"2px","h1FontWeight":"var(--lia-bs-headings-font-weight)","h2FontWeight":"var(--lia-bs-headings-font-weight)","h3FontWeight":"var(--lia-bs-headings-font-weight)","h4FontWeight":"var(--lia-bs-headings-font-weight)","h5FontWeight":"var(--lia-bs-headings-font-weight)","h6FontWeight":"var(--lia-bs-headings-font-weight)","__typename":"HeadingThemeSettings"},"icons":{"size10":"10px","size12":"12px","size14":"14px","size16":"16px","size20":"20px","size24":"24px","size30":"30px","size40":"40px","size50":"50px","size60":"60px","size80":"80px","size120":"120px","size160":"160px","__typename":"IconsThemeSettings"},"imagePreview":{"bgColor":"var(--lia-bs-gray-900)","titleColor":"var(--lia-bs-white)","controlColor":"var(--lia-bs-white)","controlBgColor":"var(--lia-bs-gray-800)","__typename":"ImagePreviewThemeSettings"},"input":{"borderColor":"var(--lia-bs-gray-600)","disabledColor":"var(--lia-bs-gray-600)","focusBorderColor":"var(--lia-bs-primary)","labelMarginBottom":"10px","btnFontSize":"var(--lia-bs-font-size-sm)","focusBoxShadow":"0 0 0 3px hsla(var(--lia-bs-primary-h), var(--lia-bs-primary-s), var(--lia-bs-primary-l), 0.2)","checkLabelMarginBottom":"2px","checkboxBorderRadius":"3px","borderRadiusSm":"var(--lia-bs-border-radius-sm)","borderRadius":"var(--lia-bs-border-radius)","borderRadiusLg":"var(--lia-bs-border-radius-lg)","formTextMarginTop":"4px","textAreaBorderRadius":"var(--lia-bs-border-radius)","activeFillColor":"var(--lia-bs-primary)","__typename":"InputThemeSettings"},"loading":{"dotDarkColor":"hsla(var(--lia-bs-black-h), var(--lia-bs-black-s), var(--lia-bs-black-l), 0.2)","dotLightColor":"hsla(var(--lia-bs-white-h), var(--lia-bs-white-s), var(--lia-bs-white-l), 0.5)","barDarkColor":"hsla(var(--lia-bs-black-h), var(--lia-bs-black-s), var(--lia-bs-black-l), 0.06)","barLightColor":"hsla(var(--lia-bs-white-h), var(--lia-bs-white-s), var(--lia-bs-white-l), 0.4)","__typename":"LoadingThemeSettings"},"link":{"color":"var(--lia-bs-primary)","hoverColor":"hsl(var(--lia-bs-primary-h), var(--lia-bs-primary-s), calc(var(--lia-bs-primary-l) - 10%))","decoration":"none","hoverDecoration":"underline","__typename":"LinkThemeSettings"},"listGroup":{"itemPaddingY":"15px","itemPaddingX":"15px","borderColor":"var(--lia-bs-gray-300)","__typename":"ListGroupThemeSettings"},"modal":{"contentTextColor":"var(--lia-bs-body-color)","contentBg":"var(--lia-bs-white)","backgroundBg":"var(--lia-bs-black)","smSize":"440px","mdSize":"760px","lgSize":"1080px","backdropOpacity":0.3,"contentBoxShadowXs":"var(--lia-bs-box-shadow-sm)","contentBoxShadow":"var(--lia-bs-box-shadow)","headerFontWeight":"700","__typename":"ModalThemeSettings"},"navbar":{"position":"FIXED","background":{"attachment":null,"clip":null,"color":"var(--lia-bs-white)","imageAssetName":null,"imageLastModified":"0","origin":null,"position":"CENTER_CENTER","repeat":"NO_REPEAT","size":"COVER","__typename":"BackgroundProps"},"backgroundOpacity":0.8,"paddingTop":"15px","paddingBottom":"15px","borderBottom":"1px solid var(--lia-bs-border-color)","boxShadow":"var(--lia-bs-box-shadow-sm)","brandMarginRight":"30px","brandMarginRightSm":"10px","brandLogoHeight":"30px","linkGap":"10px","linkJustifyContent":"flex-start","linkPaddingY":"5px","linkPaddingX":"10px","linkDropdownPaddingY":"9px","linkDropdownPaddingX":"var(--lia-nav-link-px)","linkColor":"var(--lia-bs-body-color)","linkHoverColor":"var(--lia-bs-primary)","linkFontSize":"var(--lia-bs-font-size-sm)","linkFontStyle":"NORMAL","linkFontWeight":"400","linkTextTransform":"NONE","linkLetterSpacing":"normal","linkBorderRadius":"var(--lia-bs-border-radius-sm)","linkBgColor":"transparent","linkBgHoverColor":"transparent","linkBorder":"none","linkBorderHover":"none","linkBoxShadow":"none","linkBoxShadowHover":"none","linkTextBorderBottom":"none","linkTextBorderBottomHover":"none","dropdownPaddingTop":"10px","dropdownPaddingBottom":"15px","dropdownPaddingX":"10px","dropdownMenuOffset":"2px","dropdownDividerMarginTop":"10px","dropdownDividerMarginBottom":"10px","dropdownBorderColor":"hsla(var(--lia-bs-black-h), var(--lia-bs-black-s), var(--lia-bs-black-l), 0.08)","controllerBgHoverColor":"hsla(var(--lia-bs-black-h), var(--lia-bs-black-s), var(--lia-bs-black-l), 0.1)","controllerIconColor":"var(--lia-bs-body-color)","controllerIconHoverColor":"var(--lia-bs-body-color)","controllerTextColor":"var(--lia-nav-controller-icon-color)","controllerTextHoverColor":"var(--lia-nav-controller-icon-hover-color)","controllerHighlightColor":"hsla(30, 100%, 50%)","controllerHighlightTextColor":"var(--lia-yiq-light)","controllerBorderRadius":"var(--lia-border-radius-50)","hamburgerColor":"var(--lia-nav-controller-icon-color)","hamburgerHoverColor":"var(--lia-nav-controller-icon-color)","hamburgerBgColor":"transparent","hamburgerBgHoverColor":"transparent","hamburgerBorder":"none","hamburgerBorderHover":"none","collapseMenuMarginLeft":"20px","collapseMenuDividerBg":"var(--lia-nav-link-color)","collapseMenuDividerOpacity":0.16,"__typename":"NavbarThemeSettings"},"pager":{"textColor":"var(--lia-bs-link-color)","textFontWeight":"var(--lia-font-weight-md)","textFontSize":"var(--lia-bs-font-size-sm)","__typename":"PagerThemeSettings"},"panel":{"bgColor":"var(--lia-bs-white)","borderRadius":"var(--lia-bs-border-radius)","borderColor":"var(--lia-bs-border-color)","boxShadow":"none","__typename":"PanelThemeSettings"},"popover":{"arrowHeight":"8px","arrowWidth":"16px","maxWidth":"300px","minWidth":"100px","headerBg":"var(--lia-bs-white)","borderColor":"var(--lia-bs-border-color)","borderRadius":"var(--lia-bs-border-radius)","boxShadow":"0 0.5rem 1rem hsla(var(--lia-bs-black-h), var(--lia-bs-black-s), var(--lia-bs-black-l), 0.15)","__typename":"PopoverThemeSettings"},"prism":{"color":"#000000","bgColor":"#f5f2f0","fontFamily":"var(--font-family-monospace)","fontSize":"var(--lia-bs-font-size-base)","fontWeightBold":"var(--lia-bs-font-weight-bold)","fontStyleItalic":"italic","tabSize":2,"highlightColor":"#b3d4fc","commentColor":"#62707e","punctuationColor":"#6f6f6f","namespaceOpacity":"0.7","propColor":"#990055","selectorColor":"#517a00","operatorColor":"#906736","operatorBgColor":"hsla(0, 0%, 100%, 0.5)","keywordColor":"#0076a9","functionColor":"#d3284b","variableColor":"#c14700","__typename":"PrismThemeSettings"},"rte":{"bgColor":"var(--lia-bs-white)","borderRadius":"var(--lia-panel-border-radius)","boxShadow":" var(--lia-panel-box-shadow)","customColor1":"#bfedd2","customColor2":"#fbeeb8","customColor3":"#f8cac6","customColor4":"#eccafa","customColor5":"#c2e0f4","customColor6":"#2dc26b","customColor7":"#f1c40f","customColor8":"#e03e2d","customColor9":"#b96ad9","customColor10":"#3598db","customColor11":"#169179","customColor12":"#e67e23","customColor13":"#ba372a","customColor14":"#843fa1","customColor15":"#236fa1","customColor16":"#ecf0f1","customColor17":"#ced4d9","customColor18":"#95a5a6","customColor19":"#7e8c8d","customColor20":"#34495e","customColor21":"#000000","customColor22":"#ffffff","defaultMessageHeaderMarginTop":"14px","defaultMessageHeaderMarginBottom":"10px","defaultMessageItemMarginTop":"0","defaultMessageItemMarginBottom":"10px","diffAddedColor":"hsla(170, 53%, 51%, 0.4)","diffChangedColor":"hsla(43, 97%, 63%, 0.4)","diffNoneColor":"hsla(0, 0%, 80%, 0.4)","diffRemovedColor":"hsla(9, 74%, 47%, 0.4)","specialMessageHeaderMarginTop":"14px","specialMessageHeaderMarginBottom":"10px","specialMessageItemMarginTop":"0","specialMessageItemMarginBottom":"10px","__typename":"RteThemeSettings"},"tags":{"bgColor":"var(--lia-bs-gray-200)","bgHoverColor":"var(--lia-bs-gray-400)","borderRadius":"var(--lia-bs-border-radius-sm)","color":"var(--lia-bs-body-color)","hoverColor":"var(--lia-bs-body-color)","fontWeight":"var(--lia-font-weight-md)","fontSize":"var(--lia-font-size-xxs)","textTransform":"UPPERCASE","letterSpacing":"0.5px","__typename":"TagsThemeSettings"},"toasts":{"borderRadius":"var(--lia-bs-border-radius)","paddingX":"12px","__typename":"ToastsThemeSettings"},"typography":{"fontFamilyBase":"Atkinson Hyperlegible","fontStyleBase":"NORMAL","fontWeightBase":"400","fontWeightLight":"300","fontWeightNormal":"400","fontWeightMd":"500","fontWeightBold":"700","letterSpacingSm":"normal","letterSpacingXs":"normal","lineHeightBase":"1.3","fontSizeBase":"15px","fontSizeXxs":"11px","fontSizeXs":"12px","fontSizeSm":"13px","fontSizeLg":"20px","fontSizeXl":"24px","smallFontSize":"14px","customFonts":[],"__typename":"TypographyThemeSettings"},"unstyledListItem":{"marginBottomSm":"5px","marginBottomMd":"10px","marginBottomLg":"15px","marginBottomXl":"20px","marginBottomXxl":"25px","__typename":"UnstyledListItemThemeSettings"},"yiq":{"light":"#ffffff","dark":"#000000","__typename":"YiqThemeSettings"},"colorLightness":{"primaryDark":0.36,"primaryLight":0.74,"primaryLighter":0.89,"primaryLightest":0.95,"infoDark":0.39,"infoLight":0.72,"infoLighter":0.85,"infoLightest":0.93,"successDark":0.24,"successLight":0.62,"successLighter":0.8,"successLightest":0.91,"warningDark":0.39,"warningLight":0.68,"warningLighter":0.84,"warningLightest":0.93,"dangerDark":0.41,"dangerLight":0.72,"dangerLighter":0.89,"dangerLightest":0.95,"__typename":"ColorLightnessThemeSettings"},"localOverride":false,"__typename":"Theme"},"localOverride":false},"CachedAsset:text:en_US-shared/client/components/common/Loading/LoadingDot-1744046279002":{"__typename":"CachedAsset","id":"text:en_US-shared/client/components/common/Loading/LoadingDot-1744046279002","value":{"title":"Loading..."},"localOverride":false},"CachedAsset:text:en_US-components/common/EmailVerification-1744046279002":{"__typename":"CachedAsset","id":"text:en_US-components/common/EmailVerification-1744046279002","value":{"email.verification.title":"Email Verification Required","email.verification.message.update.email":"To participate in the community, you must first verify your email address. The verification email was sent to {email}. To change your email, visit My Settings.","email.verification.message.resend.email":"To participate in the community, you must first verify your email address. The verification email was sent to {email}. Resend email."},"localOverride":false},"CachedAsset:text:en_US-pages/tags/TagPage-1744046279002":{"__typename":"CachedAsset","id":"text:en_US-pages/tags/TagPage-1744046279002","value":{"tagPageTitle":"Tag:\"{tagName}\" | {communityTitle}","tagPageForNodeTitle":"Tag:\"{tagName}\" in \"{title}\" | {communityTitle}","name":"Tags Page","tag":"Tag: {tagName}"},"localOverride":false},"Category:category:top":{"__typename":"Category","id":"category:top","entityType":"CATEGORY","displayId":"top","nodeType":"category","depth":0,"title":"Top","shortTitle":"Top"},"Category:category:Articles":{"__typename":"Category","id":"category:Articles","entityType":"CATEGORY","displayId":"Articles","nodeType":"category","depth":1,"title":"Articles","description":"HowTo's and Community News.","avatar":null,"profileSettings":{"__typename":"ProfileSettings","language":null},"parent":{"__ref":"Category:category:top"},"ancestors":{"__typename":"CoreNodeConnection","edges":[{"__typename":"CoreNodeEdge","node":{"__ref":"Community:community:zihoc95639"}}]},"userContext":{"__typename":"NodeUserContext","canAddAttachments":false,"canUpdateNode":false,"canPostMessages":false,"isSubscribed":false},"categoryPolicies":{"__typename":"CategoryPolicies","canReadNode":{"__typename":"PolicyResult","failureReason":null}},"tagPolicies":{"__typename":"TagPolicies","canSubscribeTagOnNode":{"__typename":"PolicyResult","failureReason":{"__typename":"FailureReason","message":"error.lithium.policies.labels.action.corenode.subscribe_labels.allow.accessDenied","key":"error.lithium.policies.labels.action.corenode.subscribe_labels.allow.accessDenied","args":[]}},"canManageTagDashboard":{"__typename":"PolicyResult","failureReason":{"__typename":"FailureReason","message":"error.lithium.policies.labels.action.corenode.admin_labels.allow.accessDenied","key":"error.lithium.policies.labels.action.corenode.admin_labels.allow.accessDenied","args":[]}}}},"CachedAsset:quilt:f5.prod:pages/tags/TagPage:category:Articles-1744046279014":{"__typename":"CachedAsset","id":"quilt:f5.prod:pages/tags/TagPage:category:Articles-1744046279014","value":{"id":"TagPage","container":{"id":"Common","headerProps":{"removeComponents":["community.widget.bannerWidget"],"__typename":"QuiltContainerSectionProps"},"items":[{"id":"tag-header-widget","layout":"ONE_COLUMN","bgColor":"var(--lia-bs-white)","showBorder":"BOTTOM","sectionEditLevel":"LOCKED","columnMap":{"main":[{"id":"tags.widget.TagsHeaderWidget","__typename":"QuiltComponent"}],"__typename":"OneSectionColumns"},"__typename":"OneColumnQuiltSection"},{"id":"messages-list-for-tag-widget","layout":"ONE_COLUMN","columnMap":{"main":[{"id":"messages.widget.messageListForNodeByRecentActivityWidget","props":{"viewVariant":{"type":"inline","props":{"useUnreadCount":true,"useViewCount":true,"useAuthorLogin":true,"clampBodyLines":3,"useAvatar":true,"useBoardIcon":false,"useKudosCount":true,"usePreviewMedia":true,"useTags":false,"useNode":true,"useNodeLink":true,"useTextBody":true,"truncateBodyLength":-1,"useBody":true,"useRepliesCount":true,"useSolvedBadge":true,"timeStampType":"conversation.lastPostingActivityTime","useMessageTimeLink":true,"clampSubjectLines":2}},"panelType":"divider","useTitle":false,"hideIfEmpty":false,"pagerVariant":{"type":"loadMore"},"style":"list","showTabs":true,"tabItemMap":{"default":{"mostRecent":true,"mostRecentUserContent":false,"newest":false},"additional":{"mostKudoed":true,"mostViewed":true,"mostReplies":false,"noReplies":false,"noSolutions":false,"solutions":false}}},"__typename":"QuiltComponent"}],"__typename":"OneSectionColumns"},"__typename":"OneColumnQuiltSection"}],"__typename":"QuiltContainer"},"__typename":"Quilt"},"localOverride":false},"CachedAsset:quiltWrapper:f5.prod:Common:1743756026601":{"__typename":"CachedAsset","id":"quiltWrapper:f5.prod:Common:1743756026601","value":{"id":"Common","header":{"backgroundImageProps":{"assetName":"header.jpg","backgroundSize":"COVER","backgroundRepeat":"NO_REPEAT","backgroundPosition":"LEFT_CENTER","lastModified":"1702932449000","__typename":"BackgroundImageProps"},"backgroundColor":"transparent","items":[{"id":"custom.widget.Beta_MetaNav","props":{"widgetVisibility":"signedInOrAnonymous","useTitle":true,"useBackground":false,"title":"","lazyLoad":false},"__typename":"QuiltComponent"},{"id":"community.widget.navbarWidget","props":{"showUserName":false,"showRegisterLink":true,"style":{"boxShadow":"var(--lia-bs-box-shadow-sm)","linkFontWeight":"700","controllerHighlightColor":"hsla(30, 100%, 50%)","dropdownDividerMarginBottom":"10px","hamburgerBorderHover":"none","linkFontSize":"15px","linkBoxShadowHover":"none","backgroundOpacity":0.4,"controllerBorderRadius":"var(--lia-border-radius-50)","hamburgerBgColor":"transparent","linkTextBorderBottom":"none","hamburgerColor":"var(--lia-nav-controller-icon-color)","brandLogoHeight":"48px","linkLetterSpacing":"normal","linkBgHoverColor":"transparent","collapseMenuDividerOpacity":0.16,"paddingBottom":"10px","dropdownPaddingBottom":"15px","dropdownMenuOffset":"2px","hamburgerBgHoverColor":"transparent","borderBottom":"0","hamburgerBorder":"none","dropdownPaddingX":"10px","brandMarginRightSm":"10px","linkBoxShadow":"none","linkJustifyContent":"center","linkColor":"var(--lia-bs-primary)","collapseMenuDividerBg":"var(--lia-nav-link-color)","dropdownPaddingTop":"10px","controllerHighlightTextColor":"var(--lia-yiq-dark)","background":{"imageAssetName":"","color":"var(--lia-bs-white)","size":"COVER","repeat":"NO_REPEAT","position":"CENTER_CENTER","imageLastModified":""},"linkBorderRadius":"var(--lia-bs-border-radius-sm)","linkHoverColor":"var(--lia-bs-primary)","position":"FIXED","linkBorder":"none","linkTextBorderBottomHover":"2px solid #0C5C8D","brandMarginRight":"30px","hamburgerHoverColor":"var(--lia-nav-controller-icon-color)","linkBorderHover":"none","collapseMenuMarginLeft":"20px","linkFontStyle":"NORMAL","linkPaddingX":"10px","paddingTop":"10px","linkPaddingY":"5px","linkTextTransform":"NONE","dropdownBorderColor":"hsla(var(--lia-bs-black-h), var(--lia-bs-black-s), var(--lia-bs-black-l), 0.08)","controllerBgHoverColor":"hsla(var(--lia-bs-black-h), var(--lia-bs-black-s), var(--lia-bs-black-l), 0.1)","linkDropdownPaddingX":"var(--lia-nav-link-px)","linkBgColor":"transparent","linkDropdownPaddingY":"9px","controllerIconColor":"#0C5C8D","dropdownDividerMarginTop":"10px","linkGap":"10px","controllerIconHoverColor":"#0C5C8D"},"links":{"sideLinks":[],"mainLinks":[{"children":[{"linkType":"INTERNAL","id":"migrated-link-1","params":{"boardId":"TechnicalForum","categoryId":"Forums"},"routeName":"ForumBoardPage"},{"linkType":"INTERNAL","id":"migrated-link-2","params":{"boardId":"WaterCooler","categoryId":"Forums"},"routeName":"ForumBoardPage"}],"linkType":"INTERNAL","id":"migrated-link-0","params":{"categoryId":"Forums"},"routeName":"CategoryPage"},{"children":[{"linkType":"INTERNAL","id":"migrated-link-4","params":{"boardId":"codeshare","categoryId":"CrowdSRC"},"routeName":"TkbBoardPage"},{"linkType":"INTERNAL","id":"migrated-link-5","params":{"boardId":"communityarticles","categoryId":"CrowdSRC"},"routeName":"TkbBoardPage"}],"linkType":"INTERNAL","id":"migrated-link-3","params":{"categoryId":"CrowdSRC"},"routeName":"CategoryPage"},{"children":[{"linkType":"INTERNAL","id":"migrated-link-7","params":{"boardId":"TechnicalArticles","categoryId":"Articles"},"routeName":"TkbBoardPage"},{"linkType":"INTERNAL","id":"article-series","params":{"boardId":"article-series","categoryId":"Articles"},"routeName":"TkbBoardPage"},{"linkType":"INTERNAL","id":"security-insights","params":{"boardId":"security-insights","categoryId":"Articles"},"routeName":"TkbBoardPage"},{"linkType":"INTERNAL","id":"migrated-link-8","params":{"boardId":"DevCentralNews","categoryId":"Articles"},"routeName":"TkbBoardPage"}],"linkType":"INTERNAL","id":"migrated-link-6","params":{"categoryId":"Articles"},"routeName":"CategoryPage"},{"children":[{"linkType":"INTERNAL","id":"migrated-link-10","params":{"categoryId":"CommunityGroups"},"routeName":"CategoryPage"},{"linkType":"INTERNAL","id":"migrated-link-11","params":{"categoryId":"F5-Groups"},"routeName":"CategoryPage"}],"linkType":"INTERNAL","id":"migrated-link-9","params":{"categoryId":"GroupsCategory"},"routeName":"CategoryPage"},{"children":[],"linkType":"INTERNAL","id":"migrated-link-12","params":{"boardId":"Events","categoryId":"top"},"routeName":"EventBoardPage"},{"children":[],"linkType":"INTERNAL","id":"migrated-link-13","params":{"boardId":"Suggestions","categoryId":"top"},"routeName":"IdeaBoardPage"},{"children":[],"linkType":"EXTERNAL","id":"Common-external-link","url":"https://community.f5.com/c/how-do-i","target":"SELF"}]},"className":"QuiltComponent_lia-component-edit-mode__lQ9Z6","showSearchIcon":false},"__typename":"QuiltComponent"},{"id":"community.widget.bannerWidget","props":{"backgroundColor":"transparent","visualEffects":{"showBottomBorder":false},"backgroundImageProps":{"backgroundSize":"COVER","backgroundPosition":"CENTER_CENTER","backgroundRepeat":"NO_REPEAT"},"fontColor":"#222222"},"__typename":"QuiltComponent"},{"id":"community.widget.breadcrumbWidget","props":{"backgroundColor":"var(--lia-bs-primary)","linkHighlightColor":"#FFFFFF","visualEffects":{"showBottomBorder":false},"backgroundOpacity":60,"linkTextColor":"#FFFFFF"},"__typename":"QuiltComponent"}],"__typename":"QuiltWrapperSection"},"footer":{"backgroundImageProps":{"assetName":null,"backgroundSize":"COVER","backgroundRepeat":"NO_REPEAT","backgroundPosition":"CENTER_CENTER","lastModified":null,"__typename":"BackgroundImageProps"},"backgroundColor":"var(--lia-bs-body-color)","items":[{"id":"custom.widget.Beta_Footer","props":{"widgetVisibility":"signedInOrAnonymous","useTitle":true,"useBackground":false,"title":"","lazyLoad":false},"__typename":"QuiltComponent"},{"id":"custom.widget.Tag_Manager_Helper","props":{"widgetVisibility":"signedInOrAnonymous","useTitle":true,"useBackground":false,"title":"","lazyLoad":false},"__typename":"QuiltComponent"},{"id":"custom.widget.Consent_Blackbar","props":{"widgetVisibility":"signedInOrAnonymous","useTitle":true,"useBackground":false,"title":"","lazyLoad":false},"__typename":"QuiltComponent"}],"__typename":"QuiltWrapperSection"},"__typename":"QuiltWrapper","localOverride":false},"localOverride":false},"CachedAsset:text:en_US-components/common/ActionFeedback-1744046279002":{"__typename":"CachedAsset","id":"text:en_US-components/common/ActionFeedback-1744046279002","value":{"joinedGroupHub.title":"Welcome","joinedGroupHub.message":"You are now a member of this group and are subscribed to updates.","groupHubInviteNotFound.title":"Invitation Not Found","groupHubInviteNotFound.message":"Sorry, we could not find your invitation to the group. The owner may have canceled the invite.","groupHubNotFound.title":"Group Not Found","groupHubNotFound.message":"The grouphub you tried to join does not exist. It may have been deleted.","existingGroupHubMember.title":"Already Joined","existingGroupHubMember.message":"You are already a member of this group.","accountLocked.title":"Account Locked","accountLocked.message":"Your account has been locked due to multiple failed attempts. Try again in {lockoutTime} minutes.","editedGroupHub.title":"Changes Saved","editedGroupHub.message":"Your group has been updated.","leftGroupHub.title":"Goodbye","leftGroupHub.message":"You are no longer a member of this group and will not receive future updates.","deletedGroupHub.title":"Deleted","deletedGroupHub.message":"The group has been deleted.","groupHubCreated.title":"Group Created","groupHubCreated.message":"{groupHubName} is ready to use","accountClosed.title":"Account Closed","accountClosed.message":"The account has been closed and you will now be redirected to the homepage","resetTokenExpired.title":"Reset Password Link has Expired","resetTokenExpired.message":"Try resetting your password again","invalidUrl.title":"Invalid URL","invalidUrl.message":"The URL you're using is not recognized. Verify your URL and try again.","accountClosedForUser.title":"Account Closed","accountClosedForUser.message":"{userName}'s account is closed","inviteTokenInvalid.title":"Invitation Invalid","inviteTokenInvalid.message":"Your invitation to the community has been canceled or expired.","inviteTokenError.title":"Invitation Verification Failed","inviteTokenError.message":"The url you are utilizing is not recognized. Verify your URL and try again","pageNotFound.title":"Access Denied","pageNotFound.message":"You do not have access to this area of the community or it doesn't exist","eventAttending.title":"Responded as Attending","eventAttending.message":"You'll be notified when there's new activity and reminded as the event approaches","eventInterested.title":"Responded as Interested","eventInterested.message":"You'll be notified when there's new activity and reminded as the event approaches","eventNotFound.title":"Event Not Found","eventNotFound.message":"The event you tried to respond to does not exist.","redirectToRelatedPage.title":"Showing Related Content","redirectToRelatedPageForBaseUsers.title":"Showing Related Content","redirectToRelatedPageForBaseUsers.message":"The content you are trying to access is archived","redirectToRelatedPage.message":"The content you are trying to access is archived","relatedUrl.archivalLink.flyoutMessage":"The content you are trying to access is archived View Archived Content"},"localOverride":false},"CachedAsset:component:custom.widget.Beta_MetaNav-en-1743756141111":{"__typename":"CachedAsset","id":"component:custom.widget.Beta_MetaNav-en-1743756141111","value":{"component":{"id":"custom.widget.Beta_MetaNav","template":{"id":"Beta_MetaNav","markupLanguage":"HANDLEBARS","style":null,"texts":null,"defaults":{"config":{"applicablePages":[],"description":"MetaNav menu at the top of every page.","fetchedContent":null,"__typename":"ComponentConfiguration"},"props":[],"__typename":"ComponentProperties"},"components":[{"id":"custom.widget.Beta_MetaNav","form":null,"config":null,"props":[],"__typename":"Component"}],"grouping":"CUSTOM","__typename":"ComponentTemplate"},"properties":{"config":{"applicablePages":[],"description":"MetaNav menu at the top of every page.","fetchedContent":null,"__typename":"ComponentConfiguration"},"props":[],"__typename":"ComponentProperties"},"form":null,"__typename":"Component","localOverride":false},"globalCss":null,"form":null},"localOverride":false},"CachedAsset:component:custom.widget.Beta_Footer-en-1743756141111":{"__typename":"CachedAsset","id":"component:custom.widget.Beta_Footer-en-1743756141111","value":{"component":{"id":"custom.widget.Beta_Footer","template":{"id":"Beta_Footer","markupLanguage":"HANDLEBARS","style":null,"texts":null,"defaults":{"config":{"applicablePages":[],"description":"DevCentral´s custom footer.","fetchedContent":null,"__typename":"ComponentConfiguration"},"props":[],"__typename":"ComponentProperties"},"components":[{"id":"custom.widget.Beta_Footer","form":null,"config":null,"props":[],"__typename":"Component"}],"grouping":"CUSTOM","__typename":"ComponentTemplate"},"properties":{"config":{"applicablePages":[],"description":"DevCentral´s custom footer.","fetchedContent":null,"__typename":"ComponentConfiguration"},"props":[],"__typename":"ComponentProperties"},"form":null,"__typename":"Component","localOverride":false},"globalCss":null,"form":null},"localOverride":false},"CachedAsset:component:custom.widget.Tag_Manager_Helper-en-1743756141111":{"__typename":"CachedAsset","id":"component:custom.widget.Tag_Manager_Helper-en-1743756141111","value":{"component":{"id":"custom.widget.Tag_Manager_Helper","template":{"id":"Tag_Manager_Helper","markupLanguage":"HANDLEBARS","style":null,"texts":null,"defaults":{"config":{"applicablePages":[],"description":"Helper widget to inject Tag Manager scripts into head element","fetchedContent":null,"__typename":"ComponentConfiguration"},"props":[],"__typename":"ComponentProperties"},"components":[{"id":"custom.widget.Tag_Manager_Helper","form":null,"config":null,"props":[],"__typename":"Component"}],"grouping":"CUSTOM","__typename":"ComponentTemplate"},"properties":{"config":{"applicablePages":[],"description":"Helper widget to inject Tag Manager scripts into head element","fetchedContent":null,"__typename":"ComponentConfiguration"},"props":[],"__typename":"ComponentProperties"},"form":null,"__typename":"Component","localOverride":false},"globalCss":null,"form":null},"localOverride":false},"CachedAsset:component:custom.widget.Consent_Blackbar-en-1743756141111":{"__typename":"CachedAsset","id":"component:custom.widget.Consent_Blackbar-en-1743756141111","value":{"component":{"id":"custom.widget.Consent_Blackbar","template":{"id":"Consent_Blackbar","markupLanguage":"HTML","style":null,"texts":null,"defaults":{"config":{"applicablePages":[],"description":"","fetchedContent":null,"__typename":"ComponentConfiguration"},"props":[],"__typename":"ComponentProperties"},"components":[{"id":"custom.widget.Consent_Blackbar","form":null,"config":null,"props":[],"__typename":"Component"}],"grouping":"TEXTHTML","__typename":"ComponentTemplate"},"properties":{"config":{"applicablePages":[],"description":"","fetchedContent":null,"__typename":"ComponentConfiguration"},"props":[],"__typename":"ComponentProperties"},"form":null,"__typename":"Component","localOverride":false},"globalCss":null,"form":null},"localOverride":false},"CachedAsset:text:en_US-components/community/Breadcrumb-1744046279002":{"__typename":"CachedAsset","id":"text:en_US-components/community/Breadcrumb-1744046279002","value":{"navLabel":"Breadcrumbs","dropdown":"Additional parent page navigation"},"localOverride":false},"CachedAsset:text:en_US-components/tags/TagsHeaderWidget-1744046279002":{"__typename":"CachedAsset","id":"text:en_US-components/tags/TagsHeaderWidget-1744046279002","value":{"tag":"{tagName}","topicsCount":"{count} {count, plural, one {Topic} other {Topics}}"},"localOverride":false},"CachedAsset:text:en_US-components/messages/MessageListForNodeByRecentActivityWidget-1744046279002":{"__typename":"CachedAsset","id":"text:en_US-components/messages/MessageListForNodeByRecentActivityWidget-1744046279002","value":{"title@userScope:other":"Recent Content","title@userScope:self":"Contributions","title@board:FORUM@userScope:other":"Recent Discussions","title@board:BLOG@userScope:other":"Recent Blogs","emptyDescription":"No content to show","MessageListForNodeByRecentActivityWidgetEditor.nodeScope.label":"Scope","title@instance:1706288370055":"Content Feed","title@instance:1743095186784":"Most Recent Updates","title@instance:1704317906837":"Content Feed","title@instance:1743095018194":"Most Recent Updates","title@instance:1702668293472":"Community Feed","title@instance:1743095117047":"Most Recent Updates","title@instance:1704319314827":"Blog Feed","title@instance:1743095235555":"Most Recent Updates","title@instance:1704320290851":"My Contributions","title@instance:1703720491809":"Forum Feed","title@instance:1743095311723":"Most Recent Updates","title@instance:1703028709746":"Group Content Feed","title@instance:VTsglH":"Content Feed"},"localOverride":false},"Category:category:Forums":{"__typename":"Category","id":"category:Forums","categoryPolicies":{"__typename":"CategoryPolicies","canReadNode":{"__typename":"PolicyResult","failureReason":null}}},"Forum:board:TechnicalForum":{"__typename":"Forum","id":"board:TechnicalForum","forumPolicies":{"__typename":"ForumPolicies","canReadNode":{"__typename":"PolicyResult","failureReason":null}},"boardPolicies":{"__typename":"BoardPolicies","canReadNode":{"__typename":"PolicyResult","failureReason":null}}},"Forum:board:WaterCooler":{"__typename":"Forum","id":"board:WaterCooler","forumPolicies":{"__typename":"ForumPolicies","canReadNode":{"__typename":"PolicyResult","failureReason":null}},"boardPolicies":{"__typename":"BoardPolicies","canReadNode":{"__typename":"PolicyResult","failureReason":null}}},"Tkb:board:TechnicalArticles":{"__typename":"Tkb","id":"board:TechnicalArticles","tkbPolicies":{"__typename":"TkbPolicies","canReadNode":{"__typename":"PolicyResult","failureReason":null}},"boardPolicies":{"__typename":"BoardPolicies","canReadNode":{"__typename":"PolicyResult","failureReason":null}},"displayId":"TechnicalArticles","nodeType":"board","conversationStyle":"TKB","title":"Technical Articles","shortTitle":"Technical Articles","parent":{"__ref":"Category:category:Articles"}},"Tkb:board:DevCentralNews":{"__typename":"Tkb","id":"board:DevCentralNews","tkbPolicies":{"__typename":"TkbPolicies","canReadNode":{"__typename":"PolicyResult","failureReason":null}},"boardPolicies":{"__typename":"BoardPolicies","canReadNode":{"__typename":"PolicyResult","failureReason":null}}},"Category:category:GroupsCategory":{"__typename":"Category","id":"category:GroupsCategory","categoryPolicies":{"__typename":"CategoryPolicies","canReadNode":{"__typename":"PolicyResult","failureReason":null}}},"Category:category:F5-Groups":{"__typename":"Category","id":"category:F5-Groups","categoryPolicies":{"__typename":"CategoryPolicies","canReadNode":{"__typename":"PolicyResult","failureReason":null}}},"Category:category:CommunityGroups":{"__typename":"Category","id":"category:CommunityGroups","categoryPolicies":{"__typename":"CategoryPolicies","canReadNode":{"__typename":"PolicyResult","failureReason":null}}},"Occasion:board:Events":{"__typename":"Occasion","id":"board:Events","boardPolicies":{"__typename":"BoardPolicies","canReadNode":{"__typename":"PolicyResult","failureReason":null}},"occasionPolicies":{"__typename":"OccasionPolicies","canReadNode":{"__typename":"PolicyResult","failureReason":null}}},"Idea:board:Suggestions":{"__typename":"Idea","id":"board:Suggestions","boardPolicies":{"__typename":"BoardPolicies","canReadNode":{"__typename":"PolicyResult","failureReason":null}},"ideaPolicies":{"__typename":"IdeaPolicies","canReadNode":{"__typename":"PolicyResult","failureReason":null}}},"Category:category:CrowdSRC":{"__typename":"Category","id":"category:CrowdSRC","categoryPolicies":{"__typename":"CategoryPolicies","canReadNode":{"__typename":"PolicyResult","failureReason":null}}},"Tkb:board:codeshare":{"__typename":"Tkb","id":"board:codeshare","tkbPolicies":{"__typename":"TkbPolicies","canReadNode":{"__typename":"PolicyResult","failureReason":null}},"boardPolicies":{"__typename":"BoardPolicies","canReadNode":{"__typename":"PolicyResult","failureReason":null}}},"Tkb:board:communityarticles":{"__typename":"Tkb","id":"board:communityarticles","tkbPolicies":{"__typename":"TkbPolicies","canReadNode":{"__typename":"PolicyResult","failureReason":null}},"boardPolicies":{"__typename":"BoardPolicies","canReadNode":{"__typename":"PolicyResult","failureReason":null}}},"Tkb:board:security-insights":{"__typename":"Tkb","id":"board:security-insights","tkbPolicies":{"__typename":"TkbPolicies","canReadNode":{"__typename":"PolicyResult","failureReason":null}},"boardPolicies":{"__typename":"BoardPolicies","canReadNode":{"__typename":"PolicyResult","failureReason":null}}},"Tkb:board:article-series":{"__typename":"Tkb","id":"board:article-series","tkbPolicies":{"__typename":"TkbPolicies","canReadNode":{"__typename":"PolicyResult","failureReason":null}},"boardPolicies":{"__typename":"BoardPolicies","canReadNode":{"__typename":"PolicyResult","failureReason":null}}},"Conversation:conversation:333813":{"__typename":"Conversation","id":"conversation:333813","topic":{"__typename":"TkbTopicMessage","uid":333813},"lastPostingActivityTime":"2024-09-12T05:00:00.057-07:00","solved":false},"User:user:275883":{"__typename":"User","uid":275883,"login":"Tony_Marfil","registrationData":{"__typename":"RegistrationData","status":null},"deleted":false,"avatar":{"__typename":"UserAvatar","url":"https://community.f5.com/t5/s/zihoc95639/images/dS0yNzU4ODMtQ2o3aUZ6?image-coordinates=0%2C0%2C3022%2C3022"},"id":"user:275883"},"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0zMzM4MTMtc1JNb0RL?revision=2\"}":{"__typename":"AssociatedImage","url":"https://community.f5.com/t5/s/zihoc95639/images/bS0zMzM4MTMtc1JNb0RL?revision=2","title":"1_aws_prep.png","associationType":"BODY","width":439,"height":622,"altText":""},"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0zMzM4MTMtSFBBaG4x?revision=2\"}":{"__typename":"AssociatedImage","url":"https://community.f5.com/t5/s/zihoc95639/images/bS0zMzM4MTMtSFBBaG4x?revision=2","title":"3_docker_build.png","associationType":"BODY","width":1791,"height":1501,"altText":""},"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0zMzM4MTMtcEZQeHU5?revision=2\"}":{"__typename":"AssociatedImage","url":"https://community.f5.com/t5/s/zihoc95639/images/bS0zMzM4MTMtcEZQeHU5?revision=2","title":"2_ecs_service.png","associationType":"BODY","width":2372,"height":1341,"altText":""},"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0zMzM4MTMtd3Bia3Rt?revision=2\"}":{"__typename":"AssociatedImage","url":"https://community.f5.com/t5/s/zihoc95639/images/bS0zMzM4MTMtd3Bia3Rt?revision=2","title":"4_qs_html.png","associationType":"BODY","width":1920,"height":1200,"altText":""},"TkbTopicMessage:message:333813":{"__typename":"TkbTopicMessage","subject":"Deploying F5 NGINX Plus Graviton-powered Containers as AWS ECS Fargate Tasks","conversation":{"__ref":"Conversation:conversation:333813"},"id":"message:333813","revisionNum":2,"uid":333813,"depth":0,"board":{"__ref":"Tkb:board:TechnicalArticles"},"author":{"__ref":"User:user:275883"},"teaser@stripHtml({\"removeProcessingText\":true,\"truncateLength\":-1})":" This tutorial guides users through deploying F5 NGINX Plus on AWS ECS Fargate using Graviton-powered containers, covering environment setup, custom image creation, and service deployment. ","introduction":"","metrics":{"__typename":"MessageMetrics","views":203},"postTime":"2024-09-12T05:00:00.057-07:00","lastPublishTime":"2024-09-12T05:00:00.057-07:00","body@stripHtml({\"removeProcessingText\":true,\"removeSpoilerMarkup\":true,\"removeTocMarkup\":true,\"truncateLength\":-1})":" Amazon's new cloud computing chip, Graviton4, is now generally available (July 2024). The price-performance ratio is impressive. Understandably, cloud architects are looking for solutions that: \n \n Are compatible with ARM64 and run well on Graviton \n Can run in containers and integrate into the AWS ecosystem \n \n NGINX Plus fits the bill! \n Introduction \n NGINX Plus, the commercial version of the popular open-source NGINX reverse proxy / Kubernetes Ingress Controller / load-balancer / application server, offers advanced features crucial for modern cloud architectures. NGINX Plus can effectively replace Amazon's native load-balancers and serve as a more feature-rich alternative to Elastic Kubernetes Service Ingress. Its versatility supports all cloud-native design patterns and seamlessly integrates with the AWS ecosystem. \n This tutorial leverages several AWS technologies: \n \n Graviton ARM64 instances: These offer a significant price-performance advantage over x86 instance types in AWS. \n ECS (Elastic Container Service): A fully managed container orchestration service. \n ECS Fargate: A serverless compute engine for containers, eliminating the need to provision and manage servers. \n ECR (Elastic Container Registry): A fully managed container registry for storing, managing, and deploying container images. \n AWS Secrets Manager: Securely stores and manages sensitive information like TLS certificates and private keys. \n \n What is the difference between ECS and ECS Fargate? \n The key difference between AWS ECS and AWS ECS Fargate lies in the level of infrastructure management: \n \n \n AWS ECS: \n \n You manage the underlying EC2 instances that host your containers \n You're responsible for patching, scaling, and maintaining these instances \n \n \n \n AWS ECS Fargate: \n \n Serverless compute engine for containers \n AWS manages the underlying infrastructure \n You only need to specify CPU and memory requirements for your containers \n \n \n \n In essence, Fargate abstracts away the server management aspect, allowing you to focus solely on your containerized applications, while standard ECS gives you more control but requires more hands-on management of the underlying infrastructure. \n While this tutorial doesn't cover it, NGINX Plus can send logs to CloudWatch. \n By the end of this guide, you'll have a solid understanding of how to configure, deploy, and quickly scale NGINX Plus on AWS ECS Graviton. \n Part 1: Prepare AWS Environment \n AWS Command Line version tested: \n aws --version \n aws-cli/2.17.0 Python/3.11.8 Linux/5.15.146.1-microsoft-standard-WSL2 exe/x86_64.ubuntu.20 \n 1. Set Up VPC Infrastructure \n If you already have a VPC with two public subnets, you can skip this part. \n 1.1 Create a VPC \n VPC_ID=$(aws ec2 create-vpc --cidr-block 10.0.0.0/16 --query 'Vpc.VpcId' --output text)\necho \"VPC ID: $VPC_ID\" \n 1.2 Create an Internet Gateway \n IGW_ID=$(aws ec2 create-internet-gateway --query 'InternetGateway.InternetGatewayId' --output text)\necho \"Internet Gateway ID: $IGW_ID\"\n\naws ec2 attach-internet-gateway --internet-gateway-id $IGW_ID --vpc-id $VPC_ID \n 1.3 Create Subnets \n # Get available Availability Zones\nAZS=($(aws ec2 describe-availability-zones --query 'AvailabilityZones[].ZoneName' --output text))\n\n# Create subnet in the first AZ\nSUBNET1_ID=$(aws ec2 create-subnet \\\n --vpc-id $VPC_ID \\\n --cidr-block 10.0.1.0/24 \\\n --availability-zone ${AZS[0]} \\\n --query 'Subnet.SubnetId' \\\n --output text)\n\n# Create subnet in the second AZ\nSUBNET2_ID=$(aws ec2 create-subnet \\\n --vpc-id $VPC_ID \\\n --cidr-block 10.0.2.0/24 \\\n --availability-zone ${AZS[1]} \\\n --query 'Subnet.SubnetId' \\\n --output text)\n\necho \"Subnet 1 ID: $SUBNET1_ID (AZ: ${AZS[0]})\"\necho \"Subnet 2 ID: $SUBNET2_ID (AZ: ${AZS[1]})\" \n 1.4 Set Up Routing \n ROUTE_TABLE_ID=$(aws ec2 create-route-table --vpc-id $VPC_ID --query 'RouteTable.RouteTableId' --output text)\necho \"Route Table ID: $ROUTE_TABLE_ID\"\n\naws ec2 create-route --route-table-id $ROUTE_TABLE_ID --destination-cidr-block 0.0.0.0/0 --gateway-id $IGW_ID\n\naws ec2 associate-route-table --subnet-id $SUBNET1_ID --route-table-id $ROUTE_TABLE_ID\naws ec2 associate-route-table --subnet-id $SUBNET2_ID --route-table-id $ROUTE_TABLE_ID \n 1.5 Configure Subnets for Public IP Assignment \n aws ec2 modify-subnet-attribute --subnet-id $SUBNET1_ID --map-public-ip-on-launch\naws ec2 modify-subnet-attribute --subnet-id $SUBNET2_ID --map-public-ip-on-launch \n 1.6. Create Security Group \n SG_ID=$(aws ec2 create-security-group --vpc-id $VPC_ID --group-name docker-client-sg --description \"Security group for Graviton Docker instance\" --query 'GroupId' --output text)\necho \"Security Group ID: $SG_ID\"\n\n# Allow SSH access from your IP\naws ec2 authorize-security-group-ingress --group-id $SG_ID --protocol tcp --port 22 --cidr $YOUR_IP_ADDRESS/32\n\n# Allow HTTP and HTTPS access from anywhere\naws ec2 authorize-security-group-ingress --group-id $SG_ID --protocol tcp --port 80 --cidr 0.0.0.0/0\naws ec2 authorize-security-group-ingress --group-id $SG_ID --protocol tcp --port 443 --cidr 0.0.0.0/0\n\n# Allow ICMP from anywhere (for ping)\naws ec2 authorize-security-group-ingress --group-id $SG_ID --protocol icmp --port -1 --cidr 0.0.0.0/0 \n 1.7 Create an Elastic Container Registry (ECR) \n aws ecr create-repository --repository-name my-nginx-repo --region $AWS_REGION \n \n 2. Launch an EC2 Graviton Instance \n 2.1 Find the latest Amazon Linux 2023 ARM64 AMI \n AMI_ID=$(aws ssm get-parameter --name \"/aws/service/ami-amazon-linux-latest/al2023-ami-kernel-6.1-arm64\" --query \"Parameter.Value\" --output text)\necho \"AMI ID: $AMI_ID\" \n 2.2 Launch an Amazon Linux 2023 Graviton instance \n INSTANCE_ID=$(aws ec2 run-instances \\\n --image-id $AMI_ID \\\n --instance-type t4g.micro \\\n --key-name $YOUR_KEY_NAME \\\n --security-group-ids $SG_ID \\\n --subnet-id $SUBNET1_ID \\\n --user-data '#!/bin/bash\ndnf update -y\ndnf install -y git jq docker\nsystemctl enable docker\nsystemctl start docker\nusermod -a -G docker ec2-user' \\\n --tag-specifications 'ResourceType=instance,Tags=[{Key=Name,Value=Graviton-Docker-Instance},{Key=Owner,Value=your.email@example.com}]' \\\n --query 'Instances[0].InstanceId' \\\n --output text)\necho \"Instance ID: $INSTANCE_ID\" \n Watch for progress in the AWS console. EC2 => Instances => \"Name = Graviton-Docker-Instance\". Once Status check passes (green font) you can proceed. \n 2.3 Get the public IP address of the instance \n PUBLIC_IP=$(aws ec2 describe-instances --instance-ids $INSTANCE_ID --query 'Reservations[*].Instances[*].PublicIpAddress' --output text)\necho \"Public IP: $PUBLIC_IP\" \n 2.4. Connect to the Amazon Linux 2023 instance and test Docker installation \n SSH into your Amazon Linux 2023 instance: \n ssh -i /path/to/your/key.pem ec2-user@$PUBLIC_IP # Check Docker version\ndocker --version\n\n# Run a test NGINX container\ndocker run --name mynginx -d -p 80:80 nginx\n\n# Inspect the container\ndocker inspect mynginx\n\n# Test the NGINX server\ncurl localhost\n\n# Clean up\ndocker stop $(docker ps -aq) && docker rm $(docker ps -aq) \n Part 2: Building the Custom NGINX Plus ARM64 Container \n 1. IAM Roles and Permissions \n 1.1 Create a trust policy and IAM role \n The Graviton Docker build instance will need an IAM role to access the Elastic Container Registry (ECR). \n Run these commands from your local machine or an AWS CLI enabled environment: \n # Create trust policy file\ncat > trust-policy.json << EOL\n{\n \"Version\": \"2012-10-17\",\n \"Statement\": [\n {\n \"Effect\": \"Allow\",\n \"Principal\": {\n \"Service\": \"ec2.amazonaws.com\"\n },\n \"Action\": \"sts:AssumeRole\"\n }\n ]\n}\nEOL\n\n# Create the IAM role\naws iam create-role --role-name MyEC2Role --assume-role-policy-document file://trust-policy.json\n\n# Attach the AmazonEC2ContainerRegistryFullAccess policy to the role\naws iam attach-role-policy --role-name MyEC2Role --policy-arn arn:aws:iam::aws:policy/AmazonEC2ContainerRegistryFullAccess\n\n# Create the instance profile\naws iam create-instance-profile --instance-profile-name MyEC2_InstanceProfile\n\n# Add the role to the instance profile\naws iam add-role-to-instance-profile --instance-profile-name MyEC2_InstanceProfile --role-name MyEC2Role\n\n# Associate the instance profile with your EC2 instance\naws ec2 associate-iam-instance-profile --instance-id $INSTANCE_ID --iam-instance-profile Name=MyEC2_InstanceProfile \n 2 Base NGINX Plus ARM64 Container Image \n 2.1. Sign up for NGINX Plus trial \n Sign up for an NGINX Plus trial at https://www.f5.com/trials. After signing up, you'll receive a JSON Web Token (JWT) to authenticate to private-registry.nginx.com. \n If you are an existing F5 customer, you can request a trial from the https://my.f5.com portal. \n 2.2. Connect to the Amazon Linux 2023 instance \n SSH into your Amazon Linux 2023 instance: \n ssh -i /path/to/your/key.pem ec2-user@$PUBLIC_IP \n 2.3. Set up Docker for NGINX Plus container registry \n Set up Docker to communicate with the NGINX container registry located at private-registry.nginx.com. \n Open the JSON Web Token file previously downloaded from MyF5 customer portal (for example, nginx-repo-12345abc.jwt) and copy its contents. \n Log in to the docker registry using the contents of the JSON Web Token file: \n docker login private-registry.nginx.com --username=<output_of_jwt_token> --password=none \n Next, pull the image you need from private-registry.nginx.com. \n docker pull private-registry.nginx.com/nginx-plus/base:r32 \n 2.4. Tag and Push the Base NGINX Plus image to ECR \n # Get ECR repository URI\nECR_URI=$(aws ecr describe-repositories --repository-names my-nginx-repo --query 'repositories[0].repositoryUri' --output text)\necho \"ECR Repository URI: $ECR_URI\"\n\n# Tag the base image\ndocker tag private-registry.nginx.com/nginx-plus/base:r32 $ECR_URI:r32\n\n# Authenticate Docker to ECR (if not already done)\naws ecr get-login-password --region $AWS_REGION | docker login --username AWS --password-stdin $ECR_URI\n\n# Push the base image to ECR\ndocker push $ECR_URI:r32 \n 2.5 Verify the pushed image \n aws ecr list-images --repository-name my-nginx-repo \n 3. Custom NGINX Plus ARM64 Container Image \n 3.1 Create and store ECDSA certificate and key as AWS secret \n Before we create the ECS Service, we need to generate an ECDSA certificate and key, and store them in AWS Secrets Manager. This secret will be used by the fetch_and_setup_tls.sh script in our container. \n # Generate the private key:\nopenssl ecparam -name prime256v1 -genkey -noout -out ecdsa_private_key.pem\n\n# Generate a self-signed certificate:\nopenssl req -new -x509 -key ecdsa_private_key.pem -out ecdsa_certificate.pem -days 365 -subj \"/CN=example.com\"\n\n# Create JSON formatted file that contains both the cert and key\njq -n --arg cert \"$(cat ecdsa_certificate.pem)\" --arg key \"$(cat ecdsa_private_key.pem)\" \\\n'{\"certificate\": $cert, \"private_key\": $key}' > secret.json\n\n# Store the secret in AWS Secrets Manager\naws secretsmanager create-secret --name \"MyTlsCertAndKey1\" --secret-string file://secret.json \n 3.2 Dockerfile \n docker images \n Look for the base image: \n <your-account-id>.dkr.ecr.$AWS_REGION.amazonaws.com/my-nginx-repo:r32 \n Create a Dockerfile . Replace the base image in the Dockerfile with yours. \n # Use the existing nginx image as the base\nFROM <your-account-id>.dkr.ecr.$AWS_REGION.amazonaws.com/my-nginx-repo:r32\n\n# Install necessary packages in a single layer\nRUN apt-get update && \\\n apt-get install -y awscli jq less wget vim && \\\n apt-get clean\n\n# Ensure the permissions are correct for the HTML file\nCOPY qs.html /usr/share/nginx/html/index.html\nRUN chmod 644 /usr/share/nginx/html/index.html\n\n# Copy a custom nginx configuration file\nCOPY nginx.conf /etc/nginx/nginx.conf\n\n# Script to fetch TLS cert and key from AWS Secrets Manager\nCOPY fetch_and_setup_tls.sh /usr/local/bin/fetch_and_setup_tls.sh\nRUN chmod +x /usr/local/bin/fetch_and_setup_tls.sh\n\n# Expose HTTP and HTTPS ports\nEXPOSE 80 443\n\n# Start NGINX\nCMD /usr/local/bin/fetch_and_setup_tls.sh && nginx -g 'daemon off;' \n 3.3 fetch_and_setup_tls.sh \n Create a script that will run during the task container execution process and inject a TLS certificate and key from an AWS secret: fetch_and_setup_tls.sh . \n #!/bin/bash\n\n# Set secret ID\nAWS_SECRET_ID='MyTlsCertAndKey1'\n\n# TLS_CERT_AND_KEY environment variable found?\nif [ -n \"$TLS_CERT_AND_KEY\" ]; then\n echo \"$TLS_CERT_AND_KEY\" > /tmp/secret.json\nelse\n echo \"TLS_CERT_AND_KEY not found\" > /tmp/log.txt\nfi\n\n# Extract the certificate and key files from AWS_SECRET_ID\naws secretsmanager get-secret-value --secret-id \"$AWS_SECRET_ID\" \\\n | jq -r '.SecretString | fromjson | .certificate' > /etc/nginx/ecdsa_certificate.pem\n\naws secretsmanager get-secret-value --secret-id \"$AWS_SECRET_ID\" \\\n | jq -r '.SecretString | fromjson | .private_key' > /etc/nginx/ecdsa_private_key.pem\n\n# Set permissions on the certificate and key files\nchmod 600 /etc/nginx/ecdsa_certificate.pem /etc/nginx/ecdsa_private_key.pem \n 3.4 nginx.conf \n Create your nginx.conf . \n worker_processes 1;\n\nevents {\n worker_connections 1024;\n}\n\nhttp {\n include mime.types;\n default_type application/octet-stream;\n\n sendfile on;\n keepalive_timeout 65;\n\n server {\n listen 443 ssl;\n http2 on;\n server_name _;\n\n ssl_certificate /etc/nginx/ecdsa_certificate.pem;\n ssl_certificate_key /etc/nginx/ecdsa_private_key.pem;\n\n root /usr/share/nginx/html;\n index index.html;\n\n location / {\n try_files $uri $uri/ =404;\n }\n\n # Security improvements (optional but recommended)\n ssl_protocols TLSv1.2 TLSv1.3;\n ssl_prefer_server_ciphers on;\n ssl_ciphers \"ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256\";\n ssl_session_timeout 1d;\n ssl_session_cache shared:MozSSL:10m;\n ssl_session_tickets off;\n ssl_stapling on;\n ssl_stapling_verify on;\n resolver 8.8.8.8 8.8.4.4 valid=300s;\n resolver_timeout 5s;\n add_header X-Content-Type-Options nosniff;\n add_header X-Frame-Options DENY;\n add_header X-XSS-Protection \"1; mode=block\";\n add_header Strict-Transport-Security \"max-age=31536000; includeSubDomains\" always;\n }\n\n server {\n listen 80;\n server_name _;\n\n location / {\n return 301 https://$host$request_uri;\n }\n }\n} \n 3.5 qs.html \n Create the qs.html demo html page. \n <!DOCTYPE html>\n<html lang=\"en\"><head>\n<meta http-equiv=\"content-type\" content=\"text/html; charset=UTF-8\">\n <meta charset=\"UTF-8\">\n <meta name=\"viewport\" content=\"width=device-width, initial-scale=1.0\">\n <title>QuantumSynergy AI CloudSec Solutions</title>\n <style>\n body {\n font-family: Arial, sans-serif;\n background-color: #f4f4f4;\n margin: 0;\n padding: 0;\n }\n .header {\n background-color: #282c34;\n color: white;\n padding: 20px;\n text-align: center;\n }\n .container {\n padding: 20px;\n }\n .jumbotron {\n background-color: #61dafb;\n padding: 40px;\n text-align: center;\n border-radius: 5px;\n }\n .features {\n display: flex;\n justify-content: space-around;\n margin-top: 20px;\n }\n .feature {\n background-color: white;\n padding: 20px;\n border-radius: 5px;\n box-shadow: 0 0 10px rgba(0, 0, 0, 0.1);\n width: 30%;\n text-align: center;\n }\n </style>\n</head>\n<body>\n <div class=\"header\">\n <h1>QuantumSynergy AI CloudSec Solutions</h1>\n <p>Revolutionizing Synergistic Paradigms in the Cloud</p>\n </div>\n <div class=\"container\">\n <div class=\"jumbotron\">\n <h2>Welcome to QuantumSynergy!</h2>\n <p>Leveraging Blockchain-Enhanced AI to Disrupt the Synergistic Cloud Security Landscape</p>\n </div>\n <div class=\"features\">\n <div class=\"feature\">\n <h3>AI-Powered Blockchain</h3>\n <p>Our AI integrates with blockchain technology to \nensure decentralized and autonomous synergy. Experience unparalleled \nsecurity with quantum encryption.</p>\n </div>\n <div class=\"feature\">\n <h3>Quantum Cloud Integration</h3>\n <p>By harnessing the power of quantum computing, we \noffer cloud solutions that are faster, smarter, and more secure than \never. Your data will be in a constant state of quantum flux.</p>\n </div>\n <div class=\"feature\">\n <h3>Synergistic Paradigms</h3>\n <p>Our holistic approach to cloud security brings \ntogether AI, blockchain, and quantum computing to create a synergistic \nparadigm that’s greater than the sum of its parts.</p>\n </div>\n </div>\n </div>\n</body></html> \n 3.6 Build the custom Image \n In the directory containing the Dockerfile , fetch_and_setup_tls.sh , nginx.conf , and qs.html files, run: \n docker build -t nginx-plus:r32-custom . \n 3.7 Confirm the image was built \n docker images \n 3.8 Tag and push the custom image to ECR \n # Get ECR repository URI\nECR_URI=$(aws ecr describe-repositories --repository-names my-nginx-repo --query 'repositories[0].repositoryUri' --output text)\necho \"ECR Repository URI: $ECR_URI\"\n\n# Tag the custom image\ndocker tag nginx-plus:r32-custom $ECR_URI:r32-custom\n\n# Authenticate Docker to ECR (if not already done)\naws ecr get-login-password --region $AWS_REGION | docker login --username AWS --password-stdin $ECR_URI\n\n# Push the custom image to ECR\ndocker push $ECR_URI:r32-custom \n 3.9 Verify the pushed image \n aws ecr list-images --repository-name my-nginx-repo \n \n \n Part 3: Deploying NGINX Plus on ECS Fargate \n 1. Create IAM Roles and Polices \n 1.1 Create secret-access-policy.json \n Create a file named secret-access-policy.json with the following content: \n {\n \"Version\": \"2012-10-17\",\n \"Statement\": [\n {\n \"Effect\": \"Allow\",\n \"Action\": [\n \"secretsmanager:GetSecretValue\"\n ],\n \"Resource\": \"arn:aws:secretsmanager:*:*:secret:MyTlsCertAndKey1-*\"\n }\n ]\n} \n 1.2 Create MySecretAccessPolicy \n aws iam create-policy --policy-name MySecretAccessPolicy --policy-document file://secret-access-policy.json\n\n# Get the ARN of MySecretAccessPolicy\nPOLICY_ARN=$(aws iam list-policies --query 'Policies[?PolicyName==`MySecretAccessPolicy`].Arn' --output text)\necho MySecretAccessPolicy ARN: $POLICY_ARN \n 1.3 Create MyECSTaskExecutionRole \n aws iam create-role --role-name MyECSTaskExecutionRole --assume-role-policy-document '{\n \"Version\": \"2012-10-17\",\n \"Statement\": [\n {\n \"Sid\": \"\",\n \"Effect\": \"Allow\",\n \"Principal\": {\n \"Service\": \"ecs-tasks.amazonaws.com\"\n },\n \"Action\": \"sts:AssumeRole\"\n }\n ]\n}'\n\n# Attach MySecretAccessPolicy to MyECSTaskExecutionRole\naws iam attach-role-policy \\\n --role-name MyECSTaskExecutionRole \\\n --policy-arn $POLICY_ARN\n\n# Attach AmazonECSTaskExecutionRolePolicy to MyECSTaskExecutionRole\naws iam attach-role-policy \\\n --role-name MyECSTaskExecutionRole \\\n --policy-arn arn:aws:iam::aws:policy/service-role/AmazonECSTaskExecutionRolePolicy \n 1.4 Create MyECSTaskRole \n aws iam create-role --role-name MyECSTaskRole --assume-role-policy-document '{\n \"Version\": \"2012-10-17\",\n \"Statement\": [\n {\n \"Sid\": \"\",\n \"Effect\": \"Allow\",\n \"Principal\": {\n \"Service\": \"ecs-tasks.amazonaws.com\"\n },\n \"Action\": \"sts:AssumeRole\"\n }\n ]\n}'\n\n# Attach MySecretAccessPolicy to MyECSTaskRole\naws iam attach-role-policy --role-name MyECSTaskRole --policy-arn $POLICY_ARN \n \n Note Understanding the difference between MyECSTaskExecutionRole and MyECSTaskRole is crucial for proper security configuration in ECS. \n \n \n \n MyECSTaskExecutionRole: \n \n Used by the ECS agent to launch and manage the container. \n Grants permissions to:\n \n Pull container images from ECR \n Send container logs to CloudWatch \n Retrieve sensitive data from AWS Secrets Manager or Systems Manager Parameter Store \n \n \n In our setup, it has:\n \n AmazonECSTaskExecutionRolePolicy (AWS managed policy) \n Custom policy to access our specific secret in Secrets Manager \n \n \n \n \n \n MyECSTaskRole: \n \n Used by the application running inside the container. \n Grants permissions for the application to interact with other AWS services. \n In our setup, it has:\n \n Custom policy to access our specific secret in Secrets Manager \n \n \n \n \n \n The separation of these roles adheres to the principle of least privilege. The MyECSTaskExecutionRole should have the minimum permissions needed to start and run the container, while the MyECSTaskRole needs only the permissions required by the application itself. This separation enhances security by limiting the potential impact of a compromised container. \n ECSTaskExecutionRole can be locked down further in your environment to restrict access to specific resources such as your ECR Registry and CloudWatch Log Group. \n 2. Create and Launch the ECS Service \n 2.1 Create an ECS Cluster \n aws ecs create-cluster --cluster-name my-ecs-cluster \n 2.2 Create a CloudWatch Log Group \n aws logs create-log-group --log-group-name /ecs/my-fargate-task \n 2.3. Prepare the Task Definition \n Create a file named my-fargate-task.json with the following content: \n {\n \"family\": \"my-fargate-task\",\n \"networkMode\": \"awsvpc\",\n \"containerDefinitions\": [\n {\n \"name\": \"nginx\",\n \"image\": \"<your-account-id>.dkr.ecr.$AWS_REGION.amazonaws.com/my-nginx-repo:r32-custom\",\n \"essential\": true,\n \"portMappings\": [\n {\n \"containerPort\": 80,\n \"hostPort\": 80,\n \"protocol\": \"tcp\"\n },\n {\n \"containerPort\": 443,\n \"hostPort\": 443,\n \"protocol\": \"tcp\"\n }\n ],\n \"secrets\": [\n {\n \"name\": \"TLS_CERT_AND_KEY\",\n \"valueFrom\": \"arn:aws:secretsmanager:$AWS_REGION:<your-account-id>:secret:MyTlsCertAndKey1-xxxxxx\"\n }\n ],\n \"logConfiguration\": {\n \"logDriver\": \"awslogs\",\n \"options\": {\n \"awslogs-group\": \"/ecs/my-fargate-task\",\n \"awslogs-region\": \"$AWS_REGION\",\n \"awslogs-stream-prefix\": \"ecs\"\n }\n },\n \"memory\": 512,\n \"cpu\": 256\n }\n ],\n \"requiresCompatibilities\": [\n \"FARGATE\"\n ],\n \"cpu\": \"256\",\n \"memory\": \"512\",\n \"runtimePlatform\": {\n \"operatingSystemFamily\": \"LINUX\",\n \"cpuArchitecture\": \"ARM64\"\n },\n \"executionRoleArn\": \"arn:aws:iam::<your-account-id>:role/MyECSTaskExecutionRole\",\n \"taskRoleArn\": \"arn:aws:iam::<your-account-id>:role/MyECSTaskRole\"\n} \n Replace <your-account-id> with your AWS account ID. \n 2.4. Register the Task Definition \n Register the task definition with ECS: \n aws ecs register-task-definition --cli-input-json file://my-fargate-task.json \n 2.5. Create an ECS Service \n Now, create an ECS Service to run and maintain your desired number of tasks: \n aws ecs create-service \\\n --cluster my-ecs-cluster \\\n --service-name my-fargate-service \\\n --task-definition my-fargate-task \\\n --desired-count 1 \\\n --launch-type FARGATE \\\n --network-configuration \"awsvpcConfiguration={subnets=[$SUBNET1_ID,$SUBNET2_ID],securityGroups=[$SG_ID],assignPublicIp=ENABLED}\" \\\n --enable-execute-command \n Replace $SUBNET1_ID , $SUBNET2_ID , and $SECURITY_GROUP_ID with your actual subnet and security group IDs. \n After creating the service, you can verify that the container is running in the AWS Management Console: \n \n Log in to the AWS Management Console \n Navigate to the Amazon ECS Service \n In the left sidebar, click on \"Clusters\" \n Click on the \"my-ecs-cluster\" that you created \n In the \"Services\" tab, you should see your \"my-fargate-task\" service \n Click on the service name to view details \n In the \"Tasks\" tab, you should see your running task \n \n \n \n 2.6. Scaling ECS Services across multiple tasks \n To manually scale your service from one container to two, use the following command: \n aws ecs update-service --cluster my-ecs-cluster --service my-fargate-service --desired-count 2 \n When you create or scale an ECS Service with multiple subnets specified in the network configuration, ECS uses a round-robin strategy to distribute tasks across the available subnets. In our example, the subnets were spread across different Availability Zones. This distribution helps to improve the availability and fault tolerance of your application. \n To view the current distribution of your tasks: \n aws ecs list-tasks --cluster my-ecs-cluster --service-name my-fargate-service \n Then, for each task ID, you can describe the task to see which subnet it's running in: \n aws ecs describe-tasks --cluster my-ecs-cluster --tasks <task-id> \n 2.7. Test the demo application \n After scaling your ECS Service to two containers, let's verify that both are accessible via HTTPS. To access the web pages in a browser, simply enter the HTTPS URL with the public IP \n https://<PUBLIC_IP> \n Note: Your browser will likely show a security warning because we're using a self-signed certificate. In a production environment, you would use a certificate from a trusted Certificate Authority. \n \n \n This completes our tutorial on building and deploying NGINX Plus ARM64 containers on AWS ECS Fargate. You've successfully set up the AWS environment, built a custom NGINX Plus image, deployed it to ECS Fargate, and verified HTTPS connectivity to multiple container instances. \n Remember to clean up your AWS resources when you're done to avoid unnecessary charges. \n \n Note > NGINX App Protect, the NGINX Web Application Firewall, is not compatible with Graviton (ARM64) as of August 2024. \n ","body@stripHtml({\"removeProcessingText\":true,\"removeSpoilerMarkup\":true,\"removeTocMarkup\":true,\"truncateLength\":-1})@stringLength":"26518","kudosSumWeight":1,"repliesCount":0,"readOnly":false,"images":{"__typename":"AssociatedImageConnection","edges":[{"__typename":"AssociatedImageEdge","cursor":"MjUuMnwyLjF8b3wyNXxfTlZffDE","node":{"__ref":"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0zMzM4MTMtc1JNb0RL?revision=2\"}"}},{"__typename":"AssociatedImageEdge","cursor":"MjUuMnwyLjF8b3wyNXxfTlZffDI","node":{"__ref":"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0zMzM4MTMtSFBBaG4x?revision=2\"}"}},{"__typename":"AssociatedImageEdge","cursor":"MjUuMnwyLjF8b3wyNXxfTlZffDM","node":{"__ref":"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0zMzM4MTMtcEZQeHU5?revision=2\"}"}},{"__typename":"AssociatedImageEdge","cursor":"MjUuMnwyLjF8b3wyNXxfTlZffDQ","node":{"__ref":"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0zMzM4MTMtd3Bia3Rt?revision=2\"}"}}],"totalCount":4,"pageInfo":{"__typename":"PageInfo","hasNextPage":false,"endCursor":null,"hasPreviousPage":false,"startCursor":null}},"videos":{"__typename":"VideoConnection","edges":[],"totalCount":0,"pageInfo":{"__typename":"PageInfo","hasNextPage":false,"endCursor":null,"hasPreviousPage":false,"startCursor":null}}},"Conversation:conversation:280140":{"__typename":"Conversation","id":"conversation:280140","topic":{"__typename":"TkbTopicMessage","uid":280140},"lastPostingActivityTime":"2024-09-03T20:53:48.255-07:00","solved":false},"User:user:56738":{"__typename":"User","uid":56738,"login":"ltwagnon","registrationData":{"__typename":"RegistrationData","status":null},"deleted":false,"avatar":{"__typename":"UserAvatar","url":"https://community.f5.com/t5/s/zihoc95639/images/dS01NjczOC0xNjM3OGk3QkQ0M0UxRDAzRDEzMDg3"},"id":"user:56738"},"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yODAxNDAtMTI4NzZpRTdDQTlBMERFOTY1NkU2RQ?revision=1\"}":{"__typename":"AssociatedImage","url":"https://community.f5.com/t5/s/zihoc95639/images/bS0yODAxNDAtMTI4NzZpRTdDQTlBMERFOTY1NkU2RQ?revision=1","title":"0151T000003d6BbQAI.jpg","associationType":"BODY","width":1364,"height":988,"altText":null},"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yODAxNDAtMzcxMWkxNDhBNTJFNUYyMDE2NjM5?revision=1\"}":{"__typename":"AssociatedImage","url":"https://community.f5.com/t5/s/zihoc95639/images/bS0yODAxNDAtMzcxMWkxNDhBNTJFNUYyMDE2NjM5?revision=1","title":"0151T000003d6BcQAI.jpg","associationType":"BODY","width":1288,"height":881,"altText":null},"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yODAxNDAtNjE1MGlGM0Q0MTlDNUQyMDREQUNF?revision=1\"}":{"__typename":"AssociatedImage","url":"https://community.f5.com/t5/s/zihoc95639/images/bS0yODAxNDAtNjE1MGlGM0Q0MTlDNUQyMDREQUNF?revision=1","title":"0151T000003d6BdQAI.jpg","associationType":"BODY","width":768,"height":552,"altText":null},"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yODAxNDAtNjk2NWlCNTlGMUI4ODY2MTVBNEEw?revision=1\"}":{"__typename":"AssociatedImage","url":"https://community.f5.com/t5/s/zihoc95639/images/bS0yODAxNDAtNjk2NWlCNTlGMUI4ODY2MTVBNEEw?revision=1","title":"0151T000003d6BeQAI.jpg","associationType":"BODY","width":868,"height":555,"altText":null},"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yODAxNDAtMTEzNTRpNUI0QkIyNjI5MDY0NjlDQQ?revision=1\"}":{"__typename":"AssociatedImage","url":"https://community.f5.com/t5/s/zihoc95639/images/bS0yODAxNDAtMTEzNTRpNUI0QkIyNjI5MDY0NjlDQQ?revision=1","title":"0151T000003d6BfQAI.jpg","associationType":"BODY","width":934,"height":589,"altText":null},"TkbTopicMessage:message:280140":{"__typename":"TkbTopicMessage","subject":"Using BIG-IP GTM to Integrate with Amazon Web Services","conversation":{"__ref":"Conversation:conversation:280140"},"id":"message:280140","revisionNum":1,"uid":280140,"depth":0,"board":{"__ref":"Tkb:board:TechnicalArticles"},"author":{"__ref":"User:user:56738"},"teaser@stripHtml({\"removeProcessingText\":true,\"truncateLength\":-1})":"","introduction":"","metrics":{"__typename":"MessageMetrics","views":2976},"postTime":"2014-06-18T08:00:00.000-07:00","lastPublishTime":"2014-06-18T08:00:00.000-07:00","body@stripHtml({\"removeProcessingText\":true,\"removeSpoilerMarkup\":true,\"removeTocMarkup\":true,\"truncateLength\":-1})":" This is the latest in a series of DNS articles that I've been writing over the past couple of months. This article is taken from a fantastic solution that Joe Cassidy developed. So, thanks to Joe for developing this solution, and thanks for the opportunity to write about it here on DevCentral. As a quick reminder, my first six articles are: \n\n Let's Talk DNS on DevCentral DNS The F5 Way: A Paradigm Shift DNS Express and Zone Transfers The BIG-IP GTM: Configuring DNSSEC DNS on the BIG-IP: IPv6 to IPv4 Translation DNS Caching \n\n \n\n The Scenario \n\n Let's say you are an F5 customer who has external GTMs and LTMs in your environment, but you are not leveraging them for your main website (example.com). Your website is a zone sitting on your windows DNS servers in your DMZ that round robin load balance to some backend webservers. \n\n You've heard all about the benefits of the cloud (and rightfully so), and you want to move your web content to the Amazon Cloud. Nice choice! As you were making the move to Amazon, you were given instructions by Amazon to just CNAME your domain to two unique Amazon Elastic Load Balanced (ELB) domains. Amazon’s requests were not feasible for a few reasons...one of which is that it breaks the RFC. So, you engage in a series of architecture meetings to figure all this stuff out. \n\n Amazon told your Active Directory/DNS team to CNAME www.example.com and example.com to two AWS clusters: us-east.elb.amazonaws.com and us-west.elb.amazonaws.com. You couldn't use Microsoft DNS to perform a basic CNAME of these records because of the BIND limitation of CNAME'ing a single A record to multiple aliases. Additionally, you couldn't point to IPs because Amazon said they will be using dynamic IPs for your platform. So, what to do, right? \n\n \n\n The Solution \n\n The good news is that you can use the functionality and flexibility of your F5 technology to easily solve this problem. Here are a few steps that will guide you through this specific scenario: \n\n Redirect requests for http://example.com to http://www.example.com and apply it to your Virtual Server (1.2.3.4:80). You can redirect using HTTP Class profiles (v11.3 and prior) or using a policy with Centralized Policy Matching (v11.4 and newer) or you can always write an iRule to redirect! \n\n \n\n Make www.example.com a CNAME record to example.lb.example.com; where *.lb.example.com is a sub-delegated zone of example.com that resides on your BIG-IP GTM. \n\n \n\n Create a global traffic pool “aws_us_east” that contains no members but rather a CNAME to us-east.elb.amazonaws.com. Create another global traffic pool “aws_us_west” that contains no members but rather a CNAME to us-west.elb.amazonaws.com. \n\n The following screenshot shows the details of creating the global traffic pools (using v11.5). Notice you have to select the \"Advanced\" configuration to add the CNAME. \n\n \n\n \n\n \n\n \n\n \n\n Create a global traffic Wide IP example.lb.example.com with two pool members “aws_us_east” and “aws_us_west”. The following screenshot shows the details. \n\n \n\n \n\n \n\n \n\n \n\n Create two global traffic regions: “eastern” and “western”. The screenshot below shows the details of creating the traffic regions. \n\n \n\n \n\n \n\n \n\n Create global traffic topology records using \"Request Source: Region is eastern\" and \"Destination Pool is aws_us_east\". Repeat this for the western region using the aws_us_west pool. The screenshot below shows the details of creating these records. \n\n \n\n \n\n \n\n \n\n \n\n Modify Pool settings under Wide IP www.example.com to use \"Topology\" as load balancing method. See the screenshot below for details. \n\n \n\n \n\n \n\n How it all works... \n\n Here's the flow of events that take place as a user types in the web address and ultimately receives the correct IP address. \n\n \n\n External client types http://example.com into their web browser \n\n \n\n Internet DNS resolution takes place and maps example.com to your Virtual Server address: IN A 1.2.3.4 \n\n \n\n An HTTP request is directed to 1.2.3.4:80 \n\n \n\n Your LTM checks for a profile, the HTTP profile is enabled, the redirect request is applied, and redirect user request with 301 response code is executed \n\n \n\n External client receives 301 response code and their browser makes a new request to http://www.example.com \n\n \n\n Internet DNS resolution takes place and maps www.example.com to IN CNAME example.lb.example.com \n\n \n\n Internet DNS resolution continues mapping example.lb.example.com to your GTM configured Wide IP \n\n \n\n The Wide IP load balances the request to one of the pools based on the configured logic: Round Robin, Global Availability, Topology or Ratio (we chose \"Topology\" for our solution) \n\n \n\n The GTM-configured pool contains a CNAME to either us_east or us_west AWS data centers \n\n \n\n Internet DNS resolution takes place mapping the request to the ELB hostname (i.e. us-west.elb.amazonaws.com) and gives two A records \n\n \n\n External client http request is mapped to one of the returned IP addresses \n\n \n\n \n\n And, there you have it. With this solution, you can integrate AWS using your existing LTM and GTM technology! I hope this helps, and I hope you can implement this and other solutions using all the flexibility and power of your F5 technology. \n\n ","body@stripHtml({\"removeProcessingText\":true,\"removeSpoilerMarkup\":true,\"removeTocMarkup\":true,\"truncateLength\":-1})@stringLength":"5689","kudosSumWeight":1,"repliesCount":14,"readOnly":false,"images":{"__typename":"AssociatedImageConnection","edges":[{"__typename":"AssociatedImageEdge","cursor":"MjUuMnwyLjF8b3wyNXxfTlZffDE","node":{"__ref":"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yODAxNDAtMTI4NzZpRTdDQTlBMERFOTY1NkU2RQ?revision=1\"}"}},{"__typename":"AssociatedImageEdge","cursor":"MjUuMnwyLjF8b3wyNXxfTlZffDI","node":{"__ref":"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yODAxNDAtMzcxMWkxNDhBNTJFNUYyMDE2NjM5?revision=1\"}"}},{"__typename":"AssociatedImageEdge","cursor":"MjUuMnwyLjF8b3wyNXxfTlZffDM","node":{"__ref":"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yODAxNDAtNjE1MGlGM0Q0MTlDNUQyMDREQUNF?revision=1\"}"}},{"__typename":"AssociatedImageEdge","cursor":"MjUuMnwyLjF8b3wyNXxfTlZffDQ","node":{"__ref":"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yODAxNDAtNjk2NWlCNTlGMUI4ODY2MTVBNEEw?revision=1\"}"}},{"__typename":"AssociatedImageEdge","cursor":"MjUuMnwyLjF8b3wyNXxfTlZffDU","node":{"__ref":"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yODAxNDAtMTEzNTRpNUI0QkIyNjI5MDY0NjlDQQ?revision=1\"}"}}],"totalCount":5,"pageInfo":{"__typename":"PageInfo","hasNextPage":false,"endCursor":null,"hasPreviousPage":false,"startCursor":null}},"videos":{"__typename":"VideoConnection","edges":[],"totalCount":0,"pageInfo":{"__typename":"PageInfo","hasNextPage":false,"endCursor":null,"hasPreviousPage":false,"startCursor":null}}},"Conversation:conversation:330858":{"__typename":"Conversation","id":"conversation:330858","topic":{"__typename":"TkbTopicMessage","uid":330858},"lastPostingActivityTime":"2024-07-08T05:00:00.032-07:00","solved":false},"User:user:217054":{"__typename":"User","uid":217054,"login":"C__Klewar","registrationData":{"__typename":"RegistrationData","status":null},"deleted":false,"avatar":{"__typename":"UserAvatar","url":"https://community.f5.com/t5/s/zihoc95639/images/dS0yMTcwNTQtQWhwOExV?image-coordinates=0%2C0%2C512%2C512"},"id":"user:217054"},"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0zMzA4NTgtTURVQXB6?revision=36\"}":{"__typename":"AssociatedImage","url":"https://community.f5.com/t5/s/zihoc95639/images/bS0zMzA4NTgtTURVQXB6?revision=36","title":"manual_mode_xc_topology.png","associationType":"BODY","width":1404,"height":1050,"altText":""},"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0zMzA4NTgtclBpbThn?revision=36\"}":{"__typename":"AssociatedImage","url":"https://community.f5.com/t5/s/zihoc95639/images/bS0zMzA4NTgtclBpbThn?revision=36","title":"secure_mesh_site_01.png","associationType":"BODY","width":702,"height":1399,"altText":""},"TkbTopicMessage:message:330858":{"__typename":"TkbTopicMessage","subject":"Customer-driven Site Deployment Using AWS and F5 Distributed Cloud Terraform Modules","conversation":{"__ref":"Conversation:conversation:330858"},"id":"message:330858","revisionNum":36,"uid":330858,"depth":0,"board":{"__ref":"Tkb:board:TechnicalArticles"},"author":{"__ref":"User:user:217054"},"teaser@stripHtml({\"removeProcessingText\":true,\"truncateLength\":-1})":"","introduction":"","metrics":{"__typename":"MessageMetrics","views":189},"postTime":"2024-07-08T05:00:00.032-07:00","lastPublishTime":"2024-07-08T05:00:00.032-07:00","body@stripHtml({\"removeProcessingText\":true,\"removeSpoilerMarkup\":true,\"removeTocMarkup\":true,\"truncateLength\":-1})":" Introduction and Problem Scope \n F5 Distributed Cloud Mesh’s Secure Networking provides connectivity and security services for your applications running on the Edge, Private Clouds, or Public Clouds. This simplifies the deployment and configuration of connectivity and security services for your Multi-Cloud and Edge Cloud deployment needs across heterogeneous environments. \n F5 Distributed Cloud Services leverages the “Site” construct to deploy our Secure Mesh or AppStack Site instances to manage workloads. A Site could be a customer location like AWS, Azure, GCP (Google Cloud Platform), private cloud, or an edge site. To run F5 Distributed Cloud Services, the site needs to be deployed with one or more instances of F5 Distributed Cloud Node, a software appliance that is managed by F5 Distributed Cloud Console. This site is where customer applications and F5 Distributed Cloud services are running. \n To deploy a Node, different options are available: \n \n Customer deployment topology description \n We will explain the above steps in the context of a greenfield deployment, the Terraform scripts of which are available here. The corresponding logical topology view of this deployment is shown in Fig.2. \n This deployment scenario instantiates the following resources: \n \n Single-node CE cluster \n AWS SLO interface \n AWS VPC \n AWS SLO interface subnet \n AWS route tables \n AWS Internet Gateway \n Assign AWS EIP to SLO \n \n The objective of this deployment is to create a Site with a single CE node in a new VPC for the provided AWS region and availability zone. The CE will be created as an AWS EC2 instance. An AWS subnet is created within the VPC. CE Site Local Outside (SLO) interface will be attached to VPC subnet and the created EC2 instance. SLO is a logical interface of a site (CE node) through which reachability is achieved to external (e.g. Internet or other services outside the public cloud site). To enable reachability to the Internet, the default route of the CE node will point to the AWS Internet gateway. Also, the SLO will be configured with an AWS External IP address (Elastic IP). \n \n Fig.2. Customer Deployment Topology in AWS \n List of terraform input parameters provided in vars file \n Parameters must be customized to adapt to the customer environment. The definition of the parameters in the “terraform.tfvars” show in below table. \n \n \n \n \n \n Parameters \n \n \n \n Definitions \n \n \n \n \n \n owner \n \n \n Identifies the email of the IT manager used to authenticate to the AWS system \n \n \n \n \n project_prefix \n \n \n Prefix that will be used to identify the resource objects in AWS and XC. \n \n \n \n \n project_suffix \n \n \n The suffix that will be used to identify the site’s resources in AWS and XC \n \n \n \n \n ssh_public_key_file \n \n \n Local file system’s path to ssh public key file \n \n \n \n \n f5xc_tenant \n \n \n Full F5XC tenant name \n \n \n \n \n f5xc_api_url \n \n \n F5XC API url \n \n \n \n \n f5xc_cluster_name \n \n \n Name of the Cluster \n \n \n \n \n f5xc_api_p12_file \n \n \n Local file system path to api_cert_file (downloaded from XC Console) \n \n \n \n \n aws_region \n \n \n AWS region for the XC Site \n \n \n \n \n aws_existing_vpc_id \n \n \n Existing VPC ID (brownfield) \n \n \n \n \n aws_vpc_cidr_block \n \n \n CIDR Block of the VPC \n \n \n \n \n aws_availability_zone \n \n \n AWS Availability Zone (a) \n \n \n \n \n aws_vpc_slo_subnet_node0 \n \n \n AWS Subnet in the VPC for the SLO subnet \n \n \n \n \n \n \n Configuring other environmental variables \n Export the following environment variables in the working shell, setting it to customer’s deployment context. \n \n \n \n \n \n Environment Variables \n \n \n Definitions \n \n \n \n \n AWS_ACCESS_KEY \n \n \n AWS Access key for authentication \n \n \n \n \n AWS_SECRET_ACCESS_KEY \n \n \n AWS Secret key for authentication \n \n \n \n \n VES_P12_PASSWORD \n \n \n XC P12 Password from Console \n \n \n \n \n TF_VAR_f5xc_api_p12_cert_password \n \n \n Same as VES_P12_PASSWORD \n \n \n \n \n \n \n Deploy Topology \n Deploy the topology with: \n \n terraform init \n terraform plan \n terraform deploy –auto-approve \n \n And monitor the status of the Sites on the F5 Distributed Cloud Services Console. \n Created site object will be available in Secure Mesh Site section of the F5 Distributed Cloud Services Console. \n \n Video-based description of the deployment Scenario \n This demonstration video shows the procedure for provisioning the deployment topology described above in three steps. \n References \n \n https://docs.cloud.f5.com/docs-v2/platform/services/mesh/secure-networking \n https://docs.cloud.f5.com/docs-v2/platform/concepts/site \n https://docs.cloud.f5.com/docs-v2/multi-cloud-network-connect/how-to/site-management \n https://docs.cloud.f5.com/docs-v2/multi-cloud-network-connect/how-to/site-management/deploy-aws-site-terraform \n https://docs.cloud.f5.com/docs-v2/multi-cloud-network-connect/troubleshooting/troubleshoot-manual-ce-deployment-registration-issues \n ","body@stripHtml({\"removeProcessingText\":true,\"removeSpoilerMarkup\":true,\"removeTocMarkup\":true,\"truncateLength\":-1})@stringLength":"5245","kudosSumWeight":0,"repliesCount":0,"readOnly":false,"images":{"__typename":"AssociatedImageConnection","edges":[{"__typename":"AssociatedImageEdge","cursor":"MjUuMnwyLjF8b3wyNXxfTlZffDE","node":{"__ref":"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0zMzA4NTgtTURVQXB6?revision=36\"}"}},{"__typename":"AssociatedImageEdge","cursor":"MjUuMnwyLjF8b3wyNXxfTlZffDI","node":{"__ref":"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0zMzA4NTgtclBpbThn?revision=36\"}"}}],"totalCount":2,"pageInfo":{"__typename":"PageInfo","hasNextPage":false,"endCursor":null,"hasPreviousPage":false,"startCursor":null}},"videos":{"__typename":"VideoConnection","edges":[],"totalCount":0,"pageInfo":{"__typename":"PageInfo","hasNextPage":false,"endCursor":null,"hasPreviousPage":false,"startCursor":null}}},"Conversation:conversation:330182":{"__typename":"Conversation","id":"conversation:330182","topic":{"__typename":"TkbTopicMessage","uid":330182},"lastPostingActivityTime":"2024-06-11T12:26:13.206-07:00","solved":false},"User:user:215984":{"__typename":"User","uid":215984,"login":"Heath_Parrott","registrationData":{"__typename":"RegistrationData","status":null},"deleted":false,"avatar":{"__typename":"UserAvatar","url":"https://community.f5.com/t5/s/zihoc95639/images/dS0yMTU5ODQtMjA5NTdpRkU1NkVFOUZDRDE4RTAyQw"},"id":"user:215984"},"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0zMzAxODItZVlXUk9T?revision=6\"}":{"__typename":"AssociatedImage","url":"https://community.f5.com/t5/s/zihoc95639/images/bS0zMzAxODItZVlXUk9T?revision=6","title":"F5 AWS Architectures - Cloud WAN-3.png","associationType":"BODY","width":1145,"height":545,"altText":""},"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0zMzAxODItSWgwQ2Rs?revision=6\"}":{"__typename":"AssociatedImage","url":"https://community.f5.com/t5/s/zihoc95639/images/bS0zMzAxODItSWgwQ2Rs?revision=6","title":"image.png","associationType":"BODY","width":468,"height":147,"altText":""},"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0zMzAxODItcFdQVlMy?revision=6\"}":{"__typename":"AssociatedImage","url":"https://community.f5.com/t5/s/zihoc95639/images/bS0zMzAxODItcFdQVlMy?revision=6","title":"F5 AWS Architectures - Copy of Cloud WAN.png","associationType":"BODY","width":3664,"height":1907,"altText":""},"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0zMzAxODItMGlqekh2?revision=6\"}":{"__typename":"AssociatedImage","url":"https://community.f5.com/t5/s/zihoc95639/images/bS0zMzAxODItMGlqekh2?revision=6","title":"F5 AWS Architectures - Cloud WAN Sec. VPC No GWLB-2.png","associationType":"BODY","width":843,"height":592,"altText":""},"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0zMzAxODItWWJ0Y1pR?revision=6\"}":{"__typename":"AssociatedImage","url":"https://community.f5.com/t5/s/zihoc95639/images/bS0zMzAxODItWWJ0Y1pR?revision=6","title":"F5 AWS Architectures - CloudWAN GWLB.png","associationType":"BODY","width":1618,"height":1322,"altText":""},"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0zMzAxODItQnp1YkJB?revision=6\"}":{"__typename":"AssociatedImage","url":"https://community.f5.com/t5/s/zihoc95639/images/bS0zMzAxODItQnp1YkJB?revision=6","title":"image.png","associationType":"BODY","width":468,"height":364,"altText":""},"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0zMzAxODItSFhCbm1O?revision=6\"}":{"__typename":"AssociatedImage","url":"https://community.f5.com/t5/s/zihoc95639/images/bS0zMzAxODItSFhCbm1O?revision=6","title":"CWAN_ATT.png","associationType":"BODY","width":1822,"height":309,"altText":""},"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0zMzAxODItS2YyN2FK?revision=6\"}":{"__typename":"AssociatedImage","url":"https://community.f5.com/t5/s/zihoc95639/images/bS0zMzAxODItS2YyN2FK?revision=6","title":"CWAN_POLICY.png","associationType":"BODY","width":1813,"height":266,"altText":""},"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0zMzAxODItNEF1c3dC?revision=6\"}":{"__typename":"AssociatedImage","url":"https://community.f5.com/t5/s/zihoc95639/images/bS0zMzAxODItNEF1c3dC?revision=6","title":"Intent.png","associationType":"BODY","width":1715,"height":702,"altText":""},"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0zMzAxODItOXBmRTcz?revision=6\"}":{"__typename":"AssociatedImage","url":"https://community.f5.com/t5/s/zihoc95639/images/bS0zMzAxODItOXBmRTcz?revision=6","title":"Isolate.png","associationType":"BODY","width":1368,"height":211,"altText":""},"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0zMzAxODItczlFNFZC?revision=6\"}":{"__typename":"AssociatedImage","url":"https://community.f5.com/t5/s/zihoc95639/images/bS0zMzAxODItczlFNFZC?revision=6","title":"Screenshot 2024-06-10 at 5.10.26 PM.png","associationType":"BODY","width":1188,"height":351,"altText":""},"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0zMzAxODItb3VxVmQ3?revision=6\"}":{"__typename":"AssociatedImage","url":"https://community.f5.com/t5/s/zihoc95639/images/bS0zMzAxODItb3VxVmQ3?revision=6","title":"Map.png","associationType":"BODY","width":1060,"height":283,"altText":""},"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0zMzAxODItWkoyeVI5?revision=6\"}":{"__typename":"AssociatedImage","url":"https://community.f5.com/t5/s/zihoc95639/images/bS0zMzAxODItWkoyeVI5?revision=6","title":"F5 AWS Architectures - Cloud WAN-4.png","associationType":"BODY","width":3664,"height":1907,"altText":""},"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0zMzAxODItWmlvRUdt?revision=6\"}":{"__typename":"AssociatedImage","url":"https://community.f5.com/t5/s/zihoc95639/images/bS0zMzAxODItWmlvRUdt?revision=6","title":"CLIENT_CWAN.png","associationType":"BODY","width":454,"height":229,"altText":""},"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0zMzAxODItdnJWMjZw?revision=6\"}":{"__typename":"AssociatedImage","url":"https://community.f5.com/t5/s/zihoc95639/images/bS0zMzAxODItdnJWMjZw?revision=6","title":"us-west-2-server.png","associationType":"BODY","width":1375,"height":350,"altText":""},"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0zMzAxODItZkhOcmdO?revision=6\"}":{"__typename":"AssociatedImage","url":"https://community.f5.com/t5/s/zihoc95639/images/bS0zMzAxODItZkhOcmdO?revision=6","title":"BIGIP_CWAN.png","associationType":"BODY","width":1786,"height":549,"altText":""},"TkbTopicMessage:message:330182":{"__typename":"TkbTopicMessage","subject":"Integrate BIG-IP with AWS CloudWAN Service Insertion","conversation":{"__ref":"Conversation:conversation:330182"},"id":"message:330182","revisionNum":6,"uid":330182,"depth":0,"board":{"__ref":"Tkb:board:TechnicalArticles"},"author":{"__ref":"User:user:215984"},"teaser@stripHtml({\"removeProcessingText\":true,\"truncateLength\":-1})":" AWS Cloud WAN is being adopted by many organizations and it is critical to secure traffic that traverses this service. By using F5 security solutions with AWS Cloud WAN service insertion you can enjoy the networking benefits of AWS Cloud WAN while providing the security, control and visibility your organization requires. ","introduction":"","metrics":{"__typename":"MessageMetrics","views":211},"postTime":"2024-06-11T12:26:13.206-07:00","lastPublishTime":"2024-06-11T12:26:13.206-07:00","body@stripHtml({\"removeProcessingText\":true,\"removeSpoilerMarkup\":true,\"removeTocMarkup\":true,\"truncateLength\":-1})":" As organizations develop larger hybrid cloud architectures, many are adopting a cloud-based WAN architecture. In a cloud-based WAN architecture, an organization uses the global network of a cloud provider to create the WAN between their remote facilities, data centers, and public cloud deployments. Organizations gain tremendous benefits with the ability to create over the top (OTP) WAN topologies that can be based on consumer or commercial-grade internet connections, increasing agility for the organization. \n \n This agility does come with responsibility as organizations leveraging cloud-based WAN solutions need to insert security services. To ease this integration, AWS introduced Cloud WAN service insertion, allowing users to pragmatically stitch security services into the Cloud WAN fabric. The ability to inspect traffic and mitigate the risk of threat actors pivoting across the environment is critical for organizations in every industry. This is why F5 has partnered with AWS to support organizations security needs and integrate F5 security portfolio into Cloud WAN service insertion. \n In a Cloud Wan deployment, you have a Cloud WAN, core network, policy, and segments. VPCs, VPNs, Cloud WAN Connect, or transit gateways are attached to a Cloud WAN segment, creating the network topology allowing traffic to flow. AWS Cloud WAN service insertion introduces the concept of a Network Function Group (NFG) that allows for traffic to be steered to security and inspection services based on network policy. \n \n WHY F5 \n F5 excels at creating systems that span the OSI model with our full proxy technology. The BIG-IP proxy technology allows organizations to apply advanced networking and security controls into the traffic path while inspecting and securing 30+ protocols with Advanced Firewall Module. In Addition, F5 SSL Orchestrator can be leveraged to create dynamic security chains and SSL decryption at scale for traffic traversing the WAN allowing for multi-vendor security services to be inserted via a single policy. You can read more about AFM and SSLO Orchestrator on DevCentral. \n \n Your Computing Environment \n Your organization has multiple computing environments, and you are using Cloud WAN to connect them. These computing environments are connected to Cloud WAN via an “attachment”. These attachments can be VPCs, VPNs, Connect or Transit Gateway Route Tables. \n \n In our topology, we will use VPCs for our attachments. In our diagram we have 4 VPCs (2 Prod, 2 Dev) and two segments (f5CWAN and Dev). Currently traffic flows between the Prod VPCs and the Dev VPCs and the segments cannot communicate with each other. We also deployed security services VPCs. All of these VPCs are attached to the Core Network. \n \n In our example, we will focus on how you would deploy F5 security in AWS using Cloud WAN but you could also use these services from your on-premises deployment (or any other location) that Cloud WAN Service Insertion allows you to leverage. \n Examining the Security VPC Architecture Options \n At this point, we have a general picture of a Cloud WAN. We need to explore the two options we have to architect the security VPCs. The decision comes down to using or not using AWS Gateway Load Balancer. \n Security VPC without Gateway Load Balancer \n In a security VPC without a Gateway Load Balancer, the deployment pattern consists of one BIG-IP (or HA pair of BIG-IPs using F5 Cloud Failover Extension) in each Availability Zone (AZ). For logical clarity and greatest control, some users will find that 2 subnets and 2 route tables per AZ makes the most sense to control the routing. From a forwarding standpoint, traffic enters an AZ via a Cloud WAN attachment located in a subnet. Based on that subnet’s route table (1) traffic will be forwarded to an Elastic Network Interface (ENI) on BIG-IP. When traffic leaves BIG-IP the routing table on that subnet (2) forwards the traffic back to the Cloud WAN attachment. \n \n Security VPC with Gateway Load Balancer \n In this topology we will deploy the Cloud WAN attachments in dedicated subnets, the VPC Endpoints in dedicated subnets, and then the Gateway Load Balancer and BIG-IPs. Traffic enters into the VPC via the attachment ENIs and the respective route table will steer the traffic to the VPC Endpoints. Gateway load balancer will send the traffic over a Geneve tunnel to any one of the BIG-IP instances to be processed. Traffic returned from the BIG-IP will go back over the Geneve tunnel to the gateway load balancer endpoint and the route table of the respective subnet will send the traffic back to the Cloud WAN attachment. \n \n In the firewall VPC, it is critical to leverage Appliance Mode due to the symmetric nature of traffic flows that are inspected by security services. \n \n \n What pattern should you deploy? \n Deciding between which pattern should be deployed is a combination of decisions. The pivotal decision is scalability and resiliency. By introducing Gateway Load Balancer in the topology, we can provide horizontal scale within and across AZs. This is rooted in AWS routing, where within a given route table you can only have one route for a destination. In our topology, that route is pointed towards a network interface. If that network interface belongs to an instance, then the capacity of traffic is equal to the instance. If the network interface belongs to a GWLB the capacity is N number of AFM or SSLo instances. Additionally, GWLB will address the resiliency requirements of the security instances and supports AWS Auto Scale. \n \n \n \n \n \n \n \n \n Security Tools \n \n \n Benefits \n \n \n Drawbacks \n \n \n \n \n Single Instance per AZ and CFE \n \n \n AFM, SSL Orchestrator \n \n \n Simple Topology and fewer services \n \n \n Risk of single instance failure, capacity \n \n \n \n \n Gateway Load Balanced \n \n \n AFM, SSL Orchestrator \n \n \n Great Resiliency and scale \n \n \n Complexity \n \n \n \n \n \n \n Which F5 Security Solution Should be Used? \n If the requirements are that you need to inject firewall and IPS services, then leveraging F5 AFM will meet your core requirements. You can apply the same security policy to all traffic in the environment or you can define more specific policies based on virtual server precedence. If you have more dynamic needs and would like to be able to insert additional security services into the traffic flow based on service chain polices, then F5 SSL Orchestrator would be a better match. To learn more about how SSL Orchestrator was applied to AWS Gateway Load Balancer please see the DevCentral Article on how to increase security without rearchitecting your applications. \n \n Cloud WAN Attachments \n In our validation topology, all of our systems are deployed in VPCs but you will see that the applications are attached to F5cwan segment and the security VPC is attached to a NFG. \n \n \n Mapping Attachments to function \n The attachment is placed in the NFG based on the attachment tags. In our scenario we are working with two tags, one tag, f5-cwan, attaches the VPCS to the segment f5cwan. The other tag, f5security attaches to the f5security NFG. \n \n \n In our sample deployment, we will use Cloud WAN to connect a VPC in US-EAST-1 to a VPC in US-WEST-2 and we will deploy a single Network Function group in US-EAST-1 to inspect all the traffic. Your organization can deploy Network Function groups and attachments in all, some or one region based on your needs. From an F5 standpoint, this a reflection of both AWS and your organization’s security needs. \n \n Understanding the Service Insertion Network \n Our security VPCs will be attached to our Cloud WAN via a network function group. At this point, a user leverages Cloud WAN and tells them their intent, such as if they want to inspect all traffic between attachments on the same segment or between attachments on different segments. Users can also instruct Cloud WAN if that traffic should only be inspected once or if it should be inspected by the near side and far side network function groups. In our example policy, we will instruct our Cloud WAN to inspect traffic between attachments on the same segment named f5cwan \n \n \n The area highlighted in red shows us the network function groups we have. The area highlighted in green is the policy that matches the tags on our Cloud WAN attachments to a segment or a network function group. The area highlighted in orange says that attachments on our f5cwan segment will be sent via the f5security network function group and should only be inspected one time (single hop). To create isolation on the segment we need to configure our attachments to be isolated in our segment policy. \n \n Based on this policy we have a network map topology that has an east and west VPC connected to the f5cwan segment and a security VPC that is connected to the Cloud WAN edge in us-east-1 \n \n All traffic between the two segments will flow through the security services in us-east-1. \n \n Traffic Flow Across the WAN \n Now that we understand the attachments and the VPC architectures, how should traffic flow? In our example topology, traffic will flow from a client in us-east-1 to a Cloud WAN attachment. Our Cloud WAN service insertion will instruct the system to send the traffic to the security service VPC. The routing in the security service VPC will send the traffic to the service, and if the traffic is allowed, the traffic will flow out to the server in us-west-2. On the return, traffic will repeat the pattern \n \n If we apply the flow to the original architecture, we will see a picture like this: \n \n Having an extensive background in networking, I always want to see it “on the wire” via a packet capture. So let’s test it out. I will send a ping and a curl command from my server in us-east-1 to my server in us-west-2. \n \n Looking at the server in us-west-2 \n \n Now let’s look at the BIG-IP running in my f5security network function group in us-east-1. Here you can see that the traffic was sent to the BIG-IP (in) and then sent back to the VPC network (out) \n \n \n Conclusion \n \n AWS Cloud WAN is being adopted by many organizations and it is critical to secure traffic that traverses this service. By using F5 security solutions with AWS Cloud WAN service insertion you can enjoy the networking benefits of AWS Cloud WAN while providing the security, control and visibility your organization requires. To learn more or to see it in action please contact your F5 Solutions Engineer. \n \n ","body@stripHtml({\"removeProcessingText\":true,\"removeSpoilerMarkup\":true,\"removeTocMarkup\":true,\"truncateLength\":-1})@stringLength":"10906","kudosSumWeight":0,"repliesCount":0,"readOnly":false,"images":{"__typename":"AssociatedImageConnection","edges":[{"__typename":"AssociatedImageEdge","cursor":"MjUuMnwyLjF8b3wyNXxfTlZffDE","node":{"__ref":"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0zMzAxODItZVlXUk9T?revision=6\"}"}},{"__typename":"AssociatedImageEdge","cursor":"MjUuMnwyLjF8b3wyNXxfTlZffDI","node":{"__ref":"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0zMzAxODItSWgwQ2Rs?revision=6\"}"}},{"__typename":"AssociatedImageEdge","cursor":"MjUuMnwyLjF8b3wyNXxfTlZffDM","node":{"__ref":"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0zMzAxODItcFdQVlMy?revision=6\"}"}},{"__typename":"AssociatedImageEdge","cursor":"MjUuMnwyLjF8b3wyNXxfTlZffDQ","node":{"__ref":"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0zMzAxODItMGlqekh2?revision=6\"}"}},{"__typename":"AssociatedImageEdge","cursor":"MjUuMnwyLjF8b3wyNXxfTlZffDU","node":{"__ref":"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0zMzAxODItWWJ0Y1pR?revision=6\"}"}},{"__typename":"AssociatedImageEdge","cursor":"MjUuMnwyLjF8b3wyNXxfTlZffDY","node":{"__ref":"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0zMzAxODItQnp1YkJB?revision=6\"}"}},{"__typename":"AssociatedImageEdge","cursor":"MjUuMnwyLjF8b3wyNXxfTlZffDc","node":{"__ref":"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0zMzAxODItSFhCbm1O?revision=6\"}"}},{"__typename":"AssociatedImageEdge","cursor":"MjUuMnwyLjF8b3wyNXxfTlZffDg","node":{"__ref":"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0zMzAxODItS2YyN2FK?revision=6\"}"}},{"__typename":"AssociatedImageEdge","cursor":"MjUuMnwyLjF8b3wyNXxfTlZffDk","node":{"__ref":"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0zMzAxODItNEF1c3dC?revision=6\"}"}},{"__typename":"AssociatedImageEdge","cursor":"MjUuMnwyLjF8b3wyNXxfTlZffDEw","node":{"__ref":"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0zMzAxODItOXBmRTcz?revision=6\"}"}},{"__typename":"AssociatedImageEdge","cursor":"MjUuMnwyLjF8b3wyNXxfTlZffDEx","node":{"__ref":"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0zMzAxODItczlFNFZC?revision=6\"}"}},{"__typename":"AssociatedImageEdge","cursor":"MjUuMnwyLjF8b3wyNXxfTlZffDEy","node":{"__ref":"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0zMzAxODItb3VxVmQ3?revision=6\"}"}},{"__typename":"AssociatedImageEdge","cursor":"MjUuMnwyLjF8b3wyNXxfTlZffDEz","node":{"__ref":"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0zMzAxODItWkoyeVI5?revision=6\"}"}},{"__typename":"AssociatedImageEdge","cursor":"MjUuMnwyLjF8b3wyNXxfTlZffDE0","node":{"__ref":"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0zMzAxODItWmlvRUdt?revision=6\"}"}},{"__typename":"AssociatedImageEdge","cursor":"MjUuMnwyLjF8b3wyNXxfTlZffDE1","node":{"__ref":"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0zMzAxODItdnJWMjZw?revision=6\"}"}},{"__typename":"AssociatedImageEdge","cursor":"MjUuMnwyLjF8b3wyNXxfTlZffDE2","node":{"__ref":"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0zMzAxODItZkhOcmdO?revision=6\"}"}}],"totalCount":16,"pageInfo":{"__typename":"PageInfo","hasNextPage":false,"endCursor":null,"hasPreviousPage":false,"startCursor":null}},"videos":{"__typename":"VideoConnection","edges":[],"totalCount":0,"pageInfo":{"__typename":"PageInfo","hasNextPage":false,"endCursor":null,"hasPreviousPage":false,"startCursor":null}}},"Conversation:conversation:284381":{"__typename":"Conversation","id":"conversation:284381","topic":{"__typename":"TkbTopicMessage","uid":284381},"lastPostingActivityTime":"2024-03-19T16:01:54.998-07:00","solved":false},"User:user:49688":{"__typename":"User","uid":49688,"login":"Jeff_Giroux_F5","registrationData":{"__typename":"RegistrationData","status":null},"deleted":false,"avatar":{"__typename":"UserAvatar","url":"https://community.f5.com/t5/s/zihoc95639/images/dS00OTY4OC0xNjQzMGlBMjE3NkNDMzVDOUUwOTEw"},"id":"user:49688"},"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yODQzODEtMTkxMTlpQzVCODdDMjhCN0I3NzQ4RQ?revision=8\"}":{"__typename":"AssociatedImage","url":"https://community.f5.com/t5/s/zihoc95639/images/bS0yODQzODEtMTkxMTlpQzVCODdDMjhCN0I3NzQ4RQ?revision=8","title":"cfe-diagram.gif","associationType":"BODY","width":941,"height":728,"altText":"cfe-diagram.gif"},"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yODQzODEtNTIzMmlDMTk3QTEyQUEwQkEwMDRB?revision=8\"}":{"__typename":"AssociatedImage","url":"https://community.f5.com/t5/s/zihoc95639/images/bS0yODQzODEtNTIzMmlDMTk3QTEyQUEwQkEwMDRB?revision=8","title":"0151T000003WGPAQA4.png","associationType":"BODY","width":1295,"height":731,"altText":"0151T000003WGPAQA4.png"},"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yODQzODEtMTkxMjBpNzU1MkZBQzJEQ0VDRkNGOA?revision=8\"}":{"__typename":"AssociatedImage","url":"https://community.f5.com/t5/s/zihoc95639/images/bS0yODQzODEtMTkxMjBpNzU1MkZBQzJEQ0VDRkNGOA?revision=8","title":"regional-failover.png","associationType":"BODY","width":3516,"height":1874,"altText":"regional-failover.png"},"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yODQzODEtMTEzMDBpRjUyNDYwNDQ3N0EwNzE5QQ?revision=8\"}":{"__typename":"AssociatedImage","url":"https://community.f5.com/t5/s/zihoc95639/images/bS0yODQzODEtMTEzMDBpRjUyNDYwNDQ3N0EwNzE5QQ?revision=8","title":"0151T000003WGPKQA4.png","associationType":"BODY","width":1024,"height":502,"altText":"0151T000003WGPKQA4.png"},"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yODQzODEtMTIzN2kyMDMyM0I2NDZFN0RDQTY0?revision=8\"}":{"__typename":"AssociatedImage","url":"https://community.f5.com/t5/s/zihoc95639/images/bS0yODQzODEtMTIzN2kyMDMyM0I2NDZFN0RDQTY0?revision=8","title":"0151T000003WGOeQAO.png","associationType":"BODY","width":1024,"height":577,"altText":"0151T000003WGOeQAO.png"},"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yODQzODEtMTkxMzRpMEFBQUY5NjYyNDUwNEU5Rg?revision=8\"}":{"__typename":"AssociatedImage","url":"https://community.f5.com/t5/s/zihoc95639/images/bS0yODQzODEtMTkxMzRpMEFBQUY5NjYyNDUwNEU5Rg?revision=8","title":"public-cloud-scaling-pros-cons.png","associationType":"BODY","width":1234,"height":516,"altText":"public-cloud-scaling-pros-cons.png"},"TkbTopicMessage:message:284381":{"__typename":"TkbTopicMessage","subject":"F5 High Availability - Public Cloud Guidance","conversation":{"__ref":"Conversation:conversation:284381"},"id":"message:284381","revisionNum":8,"uid":284381,"depth":0,"board":{"__ref":"Tkb:board:TechnicalArticles"},"author":{"__ref":"User:user:49688"},"teaser@stripHtml({\"removeProcessingText\":true,\"truncateLength\":-1})":"","introduction":"","metrics":{"__typename":"MessageMetrics","views":5837},"postTime":"2020-05-04T11:01:37.000-07:00","lastPublishTime":"2024-03-19T16:01:54.998-07:00","body@stripHtml({\"removeProcessingText\":true,\"removeSpoilerMarkup\":true,\"removeTocMarkup\":true,\"truncateLength\":-1})":" \n This article will provide information about BIG-IP and NGINX high availability (HA) topics that should be considered when leveraging the public cloud. There are differences between on-prem and public cloud such as cloud provider L2 networking. These differences lead to challenges in how you address HA, failover time, peer setup, scaling options, and application state. \n Topics Covered: \n \n Discuss and Define HA \n Importance of Application Behavior and Traffic Sizing \n HA Capabilities of BIG-IP and NGINX \n Various HA Deployment Options (Active/Active, Active/Standby, auto scale) \n Example Customer Scenario \n \n What is High Availability? \n High availability can mean many things to different people. Depending on the application and traffic requirements, HA requires dual data paths, redundant storage, redundant power, and compute. It means the ability to survive a failure, maintenance windows should be seamless to user, and the user experience should never suffer...ever! \n Reference: https://en.wikipedia.org/wiki/High_availability \n So what should HA provide? \n \n Synchronization of configuration data to peers (ex. configs objects) \n Synchronization of application session state (ex. persistence records) \n Enable traffic to fail over to a peer \n Locally, allow clusters of devices to act and appear as one unit \n Globally, disburse traffic via DNS and routing \n \n Importance of Application Behavior and Traffic Sizing \n Let's look at a common use case... \n \"gaming app, lots of persistent connections, client needs to hit same backend throughout entire game session\" \n Session State \n The requirement of session state is common across applications using methods like HTTP cookies, F5 iRule persistence, JSessionID, IP affinity, or hash. The session type used by the application can help you decide what migration path is right for you. Is this an app more fitting for a lift-n-shift approach...Rehost? Can the app be redesigned to take advantage of all native IaaS and PaaS technologies...Refactor? \n Reference: 6 R's of a Cloud Migration \n \n Application session state allows user to have a consistent and reliable experience \n Auto scaling L7 proxies (BIG-IP or NGINX) keep track of session state \n BIG-IP can only mirror session state to next device in cluster \n NGINX can mirror state to all devices in cluster (via zone sync) \n \n Traffic Sizing \n The cloud provider does a great job with things like scaling, but there are still cloud provider limits that affect sizing and machine instance types to keep in mind. BIG-IP and NGINX are considered network virtual appliances (NVA). They carry quota limits like other cloud objects. \n \n Google GCP VPC Resource Limits \n Azure VM Flow Limits \n AWS Instance Types \n \n Unfortunately, not all limits are documented. Key metrics for L7 proxies are typically SSL stats, throughput, connection type, and connection count. Collecting these application and traffic metrics can help identify the correct instance type. We have a list of the F5 supported BIG-IP VE platforms on F5 CloudDocs. \n F5 Products and HA Capabilities \n BIG-IP HA Capabilities \n BIG-IP supports the following HA cluster configurations: \n \n Active/Active - all devices processing traffic \n Active/Standby - one device processes traffic, others wait in standby \n Configuration sync to all devices in cluster \n L3/L4 connection sharing to next device in cluster (ex. avoids re-login) \n L5-L7 state sharing to next device in cluster (ex. IP persistence, SSL persistence, iRule UIE persistence) \n \n Reference: BIG-IP High Availability Docs \n NGINX HA Capabilities \n NGINX supports the following HA cluster configurations: \n \n Active/Active - all devices processing traffic \n Active/Standby - one device processes traffic, others wait in standby \n Configuration sync to all devices in cluster \n Mirroring connections at L3/L4 not available \n Mirroring session state to ALL devices in cluster using Zone Synchronization Module (NGINX Plus R15) \n \n Reference: NGINX High Availability Docs \n HA Methods for BIG-IP \n In the following sections, I will illustrate 3 common deployment configurations for BIG-IP in public cloud. \n \n HA for BIG-IP Design #1 - Active/Standby via API \n HA for BIG-IP Design #2 - A/A or A/S via LB \n HA for BIG-IP Design #3 - Regional Failover (multi region) \n \n HA for BIG-IP Design #1 - Active/Standby via API (multi AZ) \n This failover method uses API calls to communicate with the cloud provider and move objects (IP address, routes, etc) during failover events. The F5 Cloud Failover Extension (CFE) for BIG-IP is used to declaratively configure the HA settings. \n \n Cloud provider load balancer is NOT required \n Fail over time can be SLOW! \n Only one device actively used (other device sits idle) \n Failover uses API calls to move cloud objects, times vary (see CFE Performance and Sizing) \n \n Key Findings: \n \n Google API failover times depend on number of forwarding rules \n Azure API slow to disassociate/associate IPs to NICs (remapping) \n Azure API fast when updating routes (UDR, user defined routes) \n AWS reliable with API regarding IP moves and routes \n \n Recommendations: \n \n This design with multi AZ is more preferred than single AZ \n Recommend when \"traditional\" HA cluster required or Lift-n-Shift...Rehost \n For Azure (based on my testing)... \n \n Recommend using Azure UDR versus IP failover when possible \n Look at Failover via LB example instead for Azure \n If API method required, look at DNS solutions to provide further redundancy \n \n \n \n HA for BIG-IP Design #2 - A/A or A/S via LB (multi AZ) \n \n Cloud LB health checks the BIG-IP for up/down status \n Faster failover times (depends on cloud LB health timers) \n Cloud LB allows A/A or A/S \n \n Key difference: \n \n Increased network/compute redundancy \n Cloud load balancer required \n \n Recommendations: \n \n Use \"failover via LB\" if you require faster failover times \n For Google (based on my testing)...\n \n Recommend against \"via LB\" for IPSEC traffic (Google LB not supported) \n If load balancing IPSEC, then use \"via API\" or \"via DNS\" failover methods \n \n \n \n HA for BIG-IP Design #3 - Regional Failover via DNS (multi AZ, multi region) \n \n BIG-IP VE active/active in multiple regions \n Traffic disbursed to VEs by DNS/GSLB \n DNS/GSLB intelligent health checks for the VEs \n \n Key difference: \n \n Cloud LB is not required \n DNS logic required by clients \n Orchestration required to manage configs across each BIG-IP \n BIG-IP standalone devices (no DSC cluster limitations) \n \n Recommendations: \n \n Good for apps that handle DNS resolution well upon failover events \n Recommend when cloud LB cannot handle a particular protocol \n Recommend when customer is already using DNS to direct traffic \n Recommend for applications that have been refactored to handle session state outside of BIG-IP \n Recommend for customers with in-house skillset to orchestrate (Ansible, Terraform, etc) \n \n HA Methods for NGINX \n In the following sections, I will illustrate 2 common deployment configurations for NGINX in public cloud. \n \n HA for NGINX Design #1 - Active/Standby via API \n HA for NGINX Design #2 - Auto Scale Active/Active via LB \n \n HA for NGINX Design #1 - Active/Standby via API (multi AZ) \n \n NGINX Plus required \n Cloud provider load balancer is NOT required \n Only one device actively used (other device sits idle) \n Only available in AWS currently \n \n Recommendations: \n \n Recommend when \"traditional\" HA cluster required or Lift-n-Shift...Rehost \n \n Reference: Active-Passive HA for NGINX Plus on AWS \n HA for NGINX Design #2 - Auto Scale Active/Active via LB (multi AZ) \n \n NGINX Plus required \n Cloud LB health checks the NGINX \n Faster failover times \n \n Key difference: \n \n Increased network/compute redundancy \n Cloud load balancer required \n \n Recommendations: \n \n Recommended for apps fitting a migration type of Replatform or Refactor \n \n Reference: Active-Active HA for NGINX Plus on AWS, Active-Active HA for NGINX Plus on Google \n Pros & Cons: Public Cloud Scaling Options \n Review this handy table to understand the high level pros and cons of each deployment method. \n Example Customer Scenario #1 \n As a means to make this topic a little more real, here is a common customer scenario that shows you the decisions that go into moving an application to the public cloud. Sometimes it's as easy as a lift-n-shift, other times you might need to do a little more work. In general, public cloud is not on-prem and things might need some tweaking. Hopefully this example will give you some pointers and guidance on your next app migration to the cloud. \n Current Setup: \n \n Gaming applications \n F5 Hardware BIG-IP VIRPIONs on-prem \n Two data centers for HA redundancy \n iRule heavy configuration (TLS encryption/decryption, payload inspections) \n Session Persistence = iRule Universal Persistence (UIE), and other methods \n Biggest app \n 15K SSL TPS \n 15Gbps throughput \n 2 million concurrent connections \n 300K HTTP req/sec (L7 with TLS) \n \n Requirements for Successful Cloud Migration: \n \n Support current traffic numbers \n Support future target traffic growth \n Must run in multiple geographic regions \n Maintain session state \n Must retain all iRules in use \n \n Recommended Design for Cloud Phase #1: \n \n Migration Type: Hybrid model, on-prem + cloud, and some Rehost \n Platform: BIG-IP \n Retaining iRules means BIG-IP is required \n Licensing: High Performance BIG-IP \n Unlocks additional CPU cores past 8 (up to 24) \n extra traffic and SSL processing \n Instance type: check F5 supported BIG-IP VE platforms for accelerated networking (10Gb+) \n HA method: Active/Standby and multi-region with DNS \n iRule Universal persistence only mirrors to only next device, keep cluster size to 2 \n scale horizontally via additional HA clusters and DNS \n clients pinned to a region via DNS (on-prem or public cloud) \n inside region, local proxy cluster shares state \n \n This example comes up in customer conversations often. Based on customer requirements, in-house skillset, current operational model, and time frames there is one option that is better than the rest. A second design phase lends itself to more of a Replatform or Refactor migration type. In that case, more options can be leveraged to take advantage of cloud-native features. For example, changing the application persistence type from iRule UIE to cookie would allow BIG-IP to avoid keeping track of state. Why? With cookies, the client keeps track of that session state. Client receives a cookie, passes the cookie to L7 proxy on successive requests, proxy checks cookie value, sends to backend pool member. The requirement for L7 proxy to share session state is now removed. \n Example Customer Scenario #2 \n Here is another customer scenario. This time the application is a full suite of multimedia content. In contrast to the first scenario, this one will illustrate the benefits of rearchitecting various components allowing greater flexibility when leveraging the cloud. You still must factor in-house skill set, project time frames, and other important business (and application) requirements when deciding on the best migration type. \n Current Setup: \n \n Multimedia (Gaming, Movie, TV, Music) Platform \n BIG-IP VIPRIONs using vCMP on-prem \n Two data centers for HA redundancy \n iRule heavy (Security, Traffic Manipulation, Performance) \n Biggest App: oAuth + Cassandra for token storage (entitlements) \n \n Requirements for Success Cloud Migration: \n \n Support current traffic numbers \n Elastic auto scale for seasonal growth (ex. holidays) \n VPC peering with partners (must also bypass Web Application Firewall) \n Must support current or similar traffic manipulating in data plane \n Compatibility with existing tooling used by Business \n \n Recommended Design for Cloud Phase #1: \n \n Migration Type: Repurchase, migration BIG-IP to NGINX Plus \n Platform: NGINX \n iRules converted to JS or LUA \n Licensing: NGINX Plus \n Modules: GeoIP, LUA, JavaScript \n HA method: N+1 \n Autoscaling via Native LB \n Active Health Checks \n \n This is a great example of a Repurchase in which application characteristics can allow the various teams to explore alternative cloud migration approaches. In this scenario, it describes a phase one migration of converting BIG-IP devices to NGINX Plus devices. This example assumes the BIG-IP configurations can be somewhat easily converted to NGINX Plus, and it also assumes there is available skillset and project time allocated to properly rearchitect the application where needed. \n Summary \n OK! Brains are expanding...hopefully? We learned about high availability and what that means for applications and user experience. We touched on the importance of application behavior and traffic sizing. Then we explored the various F5 products, how they handle HA, and HA designs. These recommendations are based on my own lab testing and interactions with customers. Every scenario will carry its own requirements, and all options should be carefully considered when leveraging the public cloud. Finally, we looked at a customer scenario, discussed requirements, and design proposal. Fun! \n Resources \n Read the following articles for more guidance specific to the various cloud providers. \n \n Advanced Topologies and More on Highly Available Services \n Lightboard Lessons - BIG-IP Deployments in Azure \n Google and BIG-IP Failing Faster in the Cloud \n BIG-IP VE on Public Cloud \n High-Availability Load Balancing with NGINX Plus on Google Cloud Platform \n Using AWS Quick Starts to Deploy NGINX Plus \n NGINX on Azure \n \n ","body@stripHtml({\"removeProcessingText\":true,\"removeSpoilerMarkup\":true,\"removeTocMarkup\":true,\"truncateLength\":-1})@stringLength":"13591","kudosSumWeight":5,"repliesCount":2,"readOnly":false,"images":{"__typename":"AssociatedImageConnection","edges":[{"__typename":"AssociatedImageEdge","cursor":"MjUuMnwyLjF8b3wyNXxfTlZffDE","node":{"__ref":"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yODQzODEtMTkxMTlpQzVCODdDMjhCN0I3NzQ4RQ?revision=8\"}"}},{"__typename":"AssociatedImageEdge","cursor":"MjUuMnwyLjF8b3wyNXxfTlZffDI","node":{"__ref":"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yODQzODEtNTIzMmlDMTk3QTEyQUEwQkEwMDRB?revision=8\"}"}},{"__typename":"AssociatedImageEdge","cursor":"MjUuMnwyLjF8b3wyNXxfTlZffDM","node":{"__ref":"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yODQzODEtMTkxMjBpNzU1MkZBQzJEQ0VDRkNGOA?revision=8\"}"}},{"__typename":"AssociatedImageEdge","cursor":"MjUuMnwyLjF8b3wyNXxfTlZffDQ","node":{"__ref":"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yODQzODEtMTEzMDBpRjUyNDYwNDQ3N0EwNzE5QQ?revision=8\"}"}},{"__typename":"AssociatedImageEdge","cursor":"MjUuMnwyLjF8b3wyNXxfTlZffDU","node":{"__ref":"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yODQzODEtMTIzN2kyMDMyM0I2NDZFN0RDQTY0?revision=8\"}"}},{"__typename":"AssociatedImageEdge","cursor":"MjUuMnwyLjF8b3wyNXxfTlZffDY","node":{"__ref":"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yODQzODEtMTkxMzRpMEFBQUY5NjYyNDUwNEU5Rg?revision=8\"}"}}],"totalCount":6,"pageInfo":{"__typename":"PageInfo","hasNextPage":false,"endCursor":null,"hasPreviousPage":false,"startCursor":null}},"videos":{"__typename":"VideoConnection","edges":[],"totalCount":0,"pageInfo":{"__typename":"PageInfo","hasNextPage":false,"endCursor":null,"hasPreviousPage":false,"startCursor":null}}},"Conversation:conversation:279520":{"__typename":"Conversation","id":"conversation:279520","topic":{"__typename":"TkbTopicMessage","uid":279520},"lastPostingActivityTime":"2024-01-16T19:21:16.527-08:00","solved":false},"User:user:216790":{"__typename":"User","uid":216790,"login":"Chase_Abbott","registrationData":{"__typename":"RegistrationData","status":null},"deleted":false,"avatar":{"__typename":"UserAvatar","url":"https://community.f5.com/t5/s/zihoc95639/images/dS0yMTY3OTAtMTcxMjhpRTUxRjc5QkI2RjcxNDQ5OA"},"id":"user:216790"},"TkbTopicMessage:message:279520":{"__typename":"TkbTopicMessage","subject":"Building an OpenSSL Certificate Authority - Creating Your Root Certificate","conversation":{"__ref":"Conversation:conversation:279520"},"id":"message:279520","revisionNum":2,"uid":279520,"depth":0,"board":{"__ref":"Tkb:board:TechnicalArticles"},"author":{"__ref":"User:user:216790"},"teaser@stripHtml({\"removeProcessingText\":true,\"truncateLength\":-1})":"","introduction":"","metrics":{"__typename":"MessageMetrics","views":17198},"postTime":"2017-11-06T04:01:00.000-08:00","lastPublishTime":"2023-06-05T21:41:52.514-07:00","body@stripHtml({\"removeProcessingText\":true,\"removeSpoilerMarkup\":true,\"removeTocMarkup\":true,\"truncateLength\":-1})":" Creating Your Root Certificate Authority \n\n In our previous article, Introductions and Design Considerations for Eliptical Curves we covered the design requirements to create a two-tier ECC certificate authority based on NSA Suite B's PKI requirements. We can now begin creating our CA's root configuration. Creating the root CA requires us to generate a certificate and private key, since this is the first certificate we're creating, it will be self-signed. The root CA will not sign client and server certificates, it's job it only to create intermeidary certificates and act as the root of our chain of trust. This is standard practice across the public and private PKI configurations and so too should your lab environments. \n\n Create Your Directory Structure \n\n Create a directory to store your root CA pair and config files. \n\n \n# sudo bash\n# mkdir /root/ca\n \n\n Yep, I did that. This is for a test lab and permissions may not match real world requirements. I sudoed into bash and created everything under root; aka playing with fire. This affects ownership down the line if you chmod private key files and directories to user access only so determine for yourself what user/permission will be accessing files for certificate creation. I have a small team and trust them with root within a lab environment (snapshots allow me to be this trusting). \n\n Create your CA database to keep track of signed certificates \n\n \n# cd /root/ca\n# mkdir private certs crl\n# touch index.txt\n# echo 1000 > serial\n \n\n We begin by creating a working root directory with sub directories for the various files we'll be creating. This will allow you to apply your preferred security practices should you choose to do so. Since this is a test lab and I am operating as root, I won't be chmod'ing anything today. \n\n Create Your OpenSSL Config File \n\n OpenSSL uses configuration files to simplify/template the components of a certificate. Copy the GIST openssl_root.cnf file to /root/ca/openssl_root.cnf which is already prepared for this demo. For the root CA certificate creation, the [ CA ] section is required and will gather it's configuration from the [ CA_default ] section. \n\n \n[ ca ]\n# `man ca`\ndefault_ca = CA_default\n \n\n\n\n The [CA_default] section in the openssl_root.cnf file contains the variables OpenSSL will use for the root CA. If you're using alternate directory names from this demo, update the file accordingly. Note the long values for default days (10 years) as we don't care about renewing the root certificate anytime soon. \n\n \n [ CA_default ]\n # Directory and file locations.\n dir = /root/ca\n certs = $dir/certs\n crl_dir = $dir/crl\n new_certs_dir = $dir/certs\n database = $dir/index.txt\n serial = $dir/serial\n RANDFILE = $dir/private/.rand\n\n # The root key and root certificate.\n private_key = $dir/private/ca.cheese.key.pem\n certificate = $dir/certs/ca.cheese.crt.pem\n\n # For certificate revocation lists.\n crlnumber = $dir/crlnumber\n crl = $dir/crl/ca.cheese.crl.pem\n crl_extensions = crl_ext\n default_crl_days = 3650\n\n # SHA-1 is deprecated, so use SHA-2 or SHA-3 instead.\n default_md = sha384\n\n name_opt = ca_default\n cert_opt = ca_default\n default_days = 3650\n preserve = no\n policy = policy_strict\n \n\n\n\n For the root CA, we define [policy_strict] which will later force the intermediary's certificate to match country, state/province, and organization name fields. \n\n \n[ policy_strict ]\nThe root CA should only sign intermediate certificates that match.\n# See POLICY FORMAT section of `man ca`.\ncountryName = match\nstateOrProvinceName = match\norganizationName = match\norganizationalUnitName = optional\ncommonName = supplied\nemailAddress = optional\n \n\n\n\n The [ req ] section is used for OpenSSL certificate requests. Some of the values listed will not be used since we are manually specifying them during certificate creation. \n\n \n[ req ]\n# Options for the `req` tool (`man req`).\ndefault_bits = 4096\ndistinguished_name = req_distinguished_name\nstring_mask = utf8only\n\n# SHA-1 is deprecated, please use SHA-2 or greater instead.\ndefault_md = sha384\n\n# Extension to add when the -x509 option is used.\nx509_extensions = v3_ca\n \n\n\n\n I pre-populate the [ req_distinguished_name ] section with values I'll commonly used to save typing down the road. \n\n \n[ req_distinguished_name ]\ncountryName = Country Name (2 letter code)\nstateOrProvinceName = State or Province Name\nlocalityName = Locality Name\n0.organizationName = Organization Name\norganizationalUnitName = Organizational Unit Name\ncommonName = Common Name\nemailAddress = Email Address\n\n# Optionally, specify some defaults.\ncountryName_default = US\nstateOrProvinceName_default = WA\nlocalityName_default = Seattle\n0.organizationName_default = Grilled Cheese Inc.\norganizationalUnitName_default = Grilled Cheese Root CA\nemailAddress_default = grilledcheese@yummyinmytummy.us\n \n\n\n\n The [ v3_ca ] section will further define the Suite B PKI requirements, namely basicConstraints and acceptable keyUsage values for a CA certificate. This section will be used for creating the root CA's certificate. \n\n \n[ v3_ca ]\n# Extensions for a typical CA (`man x509v3_config`).\nsubjectKeyIdentifier = hash\nauthorityKeyIdentifier = keyid:always,issuer\nbasicConstraints = critical, CA:true\nkeyUsage = critical, digitalSignature, cRLSign, keyCertSign\n\n \n\n Selecting the Suite B compliant elliptical curve \n\n We're creating a Suite B infrastructure so we'll need to pick an acceptable curve following P-256 or P-384. To do this, run the following OpenSSL command: \n\n \nopenssl ecparam -list_curves\n \n\n This will give you a long list of options but which one to pick? Let's isolate the suites within the 256 & 384 prime fields; we can grep the results for easier curve identification. \n\n \nopenssl ecparam -list_curves | grep '256\\|384'\n \n\n And we get the following results (your results may vary depending on the version of OpenSSL running): \n\n \n# openssl ecparam -list_curves | grep '256\\|384'\n\n secp256k1 : SECG curve over a 256 bit prime field\n secp384r1 : NIST/SECG curve over a 384 bit prime field\n prime256v1: X9.62/SECG curve over a 256 bit prime field\n brainpoolP256r1: RFC 5639 curve over a 256 bit prime field\n brainpoolP256t1: RFC 5639 curve over a 256 bit prime field\n brainpoolP384r1: RFC 5639 curve over a 384 bit prime field\n brainpoolP384t1: RFC 5639 curve over a 384 bit prime field\n \n\n I am going to use secp384r1 as my curve of choice. It's good to mention that RFC5480 notes secp256r1 (not listed) is referred to as prime256v1 for this output's purpose. Why not use something larger than 384? Thank Google. People absolutely were using secp521r1 then Google dropped support for it (read Chromium Bug 478225 for more). The theory is since NSA Suite B PKI did not explicitly call out anything besides 256 or 384, the Chromium team quietly decided it wasn't needed and dropped support for it. Yea... it kinda annoyed a few people. So to avoid future browser issues, we're sticking with what's defined in public standards. \n\n Create the Root CA's Private Key \n\n Using the names defined in the openssl_root.cnf's private_key value and our selected secp384r1 ECC curve we will create and encrypt the root certificates private key. \n\n \n# openssl ecparam -genkey -name secp384r1 | openssl ec -aes256 -out private/ca.cheese.key.pem\n\n read EC key\n writing EC key\n Enter PEM pass phrase: ******\n Verifying - Enter PEM pass phrase: ******\n \n\n Note:The ecparam function within OpenSSL does not encrypt the private key like genrsa/gendsa/gendh does. Instead we combined the private key creation (openssl ecparam) with a secondary encryption command (openssl ec) to encrypt private key before it is written to disk. Keep the password safe. \n\n Create the Root CA's Certificate \n\n Using the new private key, we can now generate our root's self-signed certificate. We do this because the root has no authority above it to request trust authority from; it is the absolute source of authority in our certificate chain. \n\n \n# openssl req -config openssl_root.cnf -new -x509 -sha384 -extensions v3_ca -key private/ca.cheese.key.pem -out certs/ca.cheese.crt.pem\n\n Enter pass phrase for private/ca.cheese.key.pem: ******\n You are about to be asked to enter information that will be incorporated\n into your certificate request.\n What you are about to enter is what is called a Distinguished Name or a DN.\n There are quite a few fields but you can leave some blank\n For some fields there will be a default value,\n If you enter '.', the field will be left blank.\n -----\n Country Name (2 letter code) [US]:\n State or Province Name [WA]:\n Locality Name [Seattle]:\n Organization Name [Grilled Cheese Inc.]:\n Organizational Unit Name [Grilled Cheese Root CA]:\n Common Name []:Grilled Cheese Root Certificate Authority\n Email Address [grilledcheese@yummyinmytummy.us]:\n \n\n Using OpenSSL we can validate the Certificate contents to ensure we're following the NSA Suite B requirements. \n\n \n# openssl x509 -noout -text -in certs/ca.cheese.crt.pem\n\n Certificate:\n Data:\n Version: 3 (0x2)\n Serial Number:\n ff:bd:f5:2f:c5:0d:3d:02\n Signature Algorithm: ecdsa-with-SHA384\n Issuer: C = US, ST = WA, L = Seattle, O = Grilled Cheese Inc., OU = Grilled Cheese Root CA, CN = Grilled Cheese Inc. Root Certificate Authority, emailAddress = grilledcheese@yummyinmytummy.us\n Validity\n Not Before: Aug 22 23:53:05 2017 GMT\n Not After : Aug 20 23:53:05 2027 GMT\n Subject: C = US, ST = WA, L = Seattle, O = Grilled Cheese Inc., OU = Grilled Cheese Root CA, CN = Grilled Cheese Inc. Root Certificate Authority, emailAddress = grilledcheese@yummyinmytummy.us\n Subject Public Key Info:\n Public Key Algorithm: id-ecPublicKey\n Public-Key: (384 bit)\n pub:\n 04:a6:b7:eb:8b:9f:fc:95:03:02:20:ea:64:7f:13:\n ea:b7:75:9b:cd:5e:43:ca:19:70:17:e2:0a:26:79:\n 0a:23:2f:20:de:02:2d:7c:8f:62:6b:74:7d:82:fe:\n 04:08:38:77:b7:8c:e0:e4:2b:27:0f:47:01:64:38:\n cb:15:a8:71:43:b2:d9:ff:ea:0e:d1:c8:f4:8f:99:\n d3:8e:2b:c1:90:d6:77:ab:0b:31:dd:78:d3:ce:96:\n b1:a0:c0:1c:b0:31:39\n ASN1 OID: secp384r1\n NIST CURVE: P-384\n X509v3 extensions:\n X509v3 Subject Key Identifier:\n 27:C8:F7:34:2F:30:81:97:DE:2E:FC:DD:E2:1D:FD:B6:8F:5A:AF:BB\n X509v3 Authority Key Identifier:\n keyid:27:C8:F7:34:2F:30:81:97:DE:2E:FC:DD:E2:1D:FD:B6:8F:5A:AF:BB\n\n X509v3 Basic Constraints: critical\n CA:TRUE\n X509v3 Key Usage: critical\n Digital Signature, Certificate Sign, CRL Sign\n Signature Algorithm: ecdsa-with-SHA384\n 30:65:02:30:77:a1:f9:e2:ab:3a:5a:4b:ce:8d:6a:2e:30:3f:\n 01:cf:8e:76:dd:f6:1f:03:d9:b3:5c:a1:3d:6d:36:04:fb:01:\n f7:33:27:03:85:de:24:56:17:c9:1a:e4:3b:35:c4:a8:02:31:\n 00:cd:0e:6c:e0:d5:26:d3:fb:88:56:fa:67:9f:e9:be:b4:8f:\n 94:1c:2c:b7:74:19:ce:ec:15:d2:fe:48:93:0a:5f:ff:eb:b2:\n d3:ae:5a:68:87:dc:c9:2c:54:8d:04:68:7f\n \n\n Reviewing the above we can verify the certificate details: \n\n The Suite B Signature Algorithm: ecdsa-with-SHA384 The certificate date validity when we specificed -days 3650:\n\t Not Before: Aug 22 23:53:05 2017 GMT Not After : Aug 20 23:53:05 2027 GMT \n\t The Public-Key bit length: (384 bit) The Issuer we defined in the openssl_root.cnf: C = US, ST = WA, L = Seattle, O = Grilled Cheese Inc., OU = Grilled Cheese Root CA, CN = Grilled Cheese Inc. Root Certificate Authority The Certificate Subject, since this is self-signed, refers back to itself: Subject: C = US, ST = WA, L = Seattle, O = Grilled Cheese Inc., OU = Grilled Cheese Root CA, CN = Grilled Cheese Inc. Root Certificate Authority The eliptical curve used when we created the private key: NIST CURVE: P-384 \n\n Verify the X.509 v3 extensions we defined within the openssl_root.cnf for a Suite B CA use: \n\n \nX509v3 Basic Constraints: critical\n CA:TRUE\nX509v3 Key Usage: critical\n Digital Signature, Certificate Sign, CRL Sign\n \n\n\n\n The root certificate and private key are now compete and we have the first part of our CA complete. Step 1 complete! In our next article we will create the intermediary certificate to complete the chain of trust in our two-tier hierarchy. ","body@stripHtml({\"removeProcessingText\":true,\"removeSpoilerMarkup\":true,\"removeTocMarkup\":true,\"truncateLength\":-1})@stringLength":"13078","kudosSumWeight":0,"repliesCount":8,"readOnly":false,"images":{"__typename":"AssociatedImageConnection","edges":[],"totalCount":0,"pageInfo":{"__typename":"PageInfo","hasNextPage":false,"endCursor":null,"hasPreviousPage":false,"startCursor":null}},"videos":{"__typename":"VideoConnection","edges":[],"totalCount":0,"pageInfo":{"__typename":"PageInfo","hasNextPage":false,"endCursor":null,"hasPreviousPage":false,"startCursor":null}}},"Conversation:conversation:279497":{"__typename":"Conversation","id":"conversation:279497","topic":{"__typename":"TkbTopicMessage","uid":279497},"lastPostingActivityTime":"2024-01-16T19:18:49.394-08:00","solved":false},"TkbTopicMessage:message:279497":{"__typename":"TkbTopicMessage","subject":"Building an OpenSSL Certificate Authority - Creating Your Intermediary Certificate","conversation":{"__ref":"Conversation:conversation:279497"},"id":"message:279497","revisionNum":3,"uid":279497,"depth":0,"board":{"__ref":"Tkb:board:TechnicalArticles"},"author":{"__ref":"User:user:216790"},"teaser@stripHtml({\"removeProcessingText\":true,\"truncateLength\":-1})":"","introduction":"","metrics":{"__typename":"MessageMetrics","views":10810},"postTime":"2017-11-06T04:02:00.000-08:00","lastPublishTime":"2023-06-05T21:41:50.597-07:00","body@stripHtml({\"removeProcessingText\":true,\"removeSpoilerMarkup\":true,\"removeTocMarkup\":true,\"truncateLength\":-1})":" Creating Your Intermediary Certificate Authority \n Previously we created the first part of our OpenSSL CA by building our root certificate. We are now ready to complete our CA chain by creating and signing the intermediary certificate. The intermediary will be responsible for signing client and server certificate requests. It acts as an authoritative proxy for the root certificate hence the name intermediary. The chain of trust will extend from the root certificate to the intermediary certificate down to the certificates you'll deploy within your infrastructure. \n Create your directory structure \n Create a new subdirectory under /root/ca to segregate intermediary files our root configuration . \n # sudo bash\n# mkdir /root/ca/intermediate\n \n We're creating the same directory structure previously used under /root/ca within /root/ca/intermediary . It's your decision if you if you want to do something different. Some of my best friends are flat directory structures and we don't judge personal practices. \n Create your intermediary CA database to keep track of signed certificates \n # cd /root/ca/intermediate\n# mkdir certs crl csr private\n# touch index.txt\n# echo 1000 > serial\n \n Create a crlnumber file for the intermediary CA to use \n # echo 1000 > /root/ca/intermediate/crlnumber\n \n Similar to the earlier serial statement, this will create the crlnumber file and start the numerical iteration at 1000. This will be used for future certificate revocation needs. \n Create your OpenSSL intermediary config file \n Copy the GIST openssl_intermediate.cnf file to /root/ca/intermediate/openssl_intermediate.cnf and modify the contents for your own naming conventions. Similar to the root_ca.cnf , the [CA] is required and will gather it's configuration from the [CA_default] section. Changes to the [int_ca] include: \n [ CA_default ]\n# Directory and file locations.\ndir = /root/ca/intermediate\nprivate_key = $dir/private/int.cheese.key.pem\ncertificate = $dir/cers/int.cheese.crt.pem\ncrlnumber = $dir/crlnumber\ncrl = $dir/crl/int.cheese.crl.pem\ncrl_extensions = crl_ext\npolicy = policy_loose\n \n We have new certificate names for our intermediary use and define policy_loose so future certificate requests don't have to match country, state/province, or organization. \n Create the Intermediary's Private Key and Certificate Signing Request \n Similar to the root certificate, we're following the NSA Suite B requirements and matching the root's elliptical curve, secp384r1. We'll also create the CSR and private key all in one line, making your scripts and life a bit easier. \n # cd /root/ca\n# openssl req -config intermediate/openssl_intermediate.cnf -new -newkey ec:<(openssl ecparam -name secp384r1) -keyout intermediate/private/int.cheese.key.pem -out intermediate/csr/int.cheese.csr\n\nGenerating an EC private key\nwriting new private key to 'intermediate/private/int.cheese.key.pem'\nEnter PEM pass phrase: ******\nVerifying - Enter PEM pass phrase: ******\n-----\nYou are about to be asked to enter information that will be incorporated\ninto your certificate request.\nWhat you are about to enter is what is called a Distinguished Name or a DN.\nThere are quite a few fields but you can leave some blank\nFor some fields there will be a default value,\nIf you enter '.', the field will be left blank.\n-----\nCountry Name (2 letter code) [US]:\nState or Province Name [WA]:\nLocality Name [Seattle]:\nOrganization Name [Grilled Cheese Inc.]:\nOrganizational Unit Name [Grilled Cheese Intermediary CA]:\nCommon Name []:Grilled Cheese Inc. Intermediary Certificate Authority\nEmail Address [grilledcheese@yummyinmytummy.us]:\n \n Sign the certificate request with the root certificate and use the openssl_intermediate.cnf config file to specify the [v3_intermediate_ca] extension instead of the [v3_ca] as we did for the root. The openssl_intermediate.cnf has a few changes which we need to note. \n [ v3_intermediate_ca ]\n# Extensions for a typical intermediate CA (`man x509v3_config`).\nsubjectKeyIdentifier = hash\nauthorityKeyIdentifier = keyid:always,issuer\nbasicConstraints = critical, CA:true, pathlen:0\nkeyUsage = critical, digitalSignature, cRLSign, keyCertSign\ncrlDistributionPoints = @crl_info\nauthorityInfoAccess = @ocsp_info\n\n[crl_info]\nURI.0 = http://crl.grilledcheese.us/whoremovedmycheese.crl\n\n[ocsp_info]\ncaIssuers;URI.0 = http://ocsp.grilledcheese.us/cheddarcheeseroot.crt\nOCSP;URI.0 = http://ocsp.grilledcheese.us/\n \n The Certificate Revocation List (crl) and Online Certificate Status Protocol (OCSP) should be included within the intermediary certificate. This lets systems know where check and see if the intermediary certificate was revoked by the root at any given time. We will cover this in detail later and browsers do not necessarily check the intermediary certificates for revocation, but they absolutely do for the site certificates. We're adding CRL and OCSP to the Intermediary CA for best practices purpose. \n Create the intermediate certificate \n Sign the csr/int.cheese.cs r with the root's certificate. We are going to drop down to /root/ca so the creation of the intermediary certificate is stored within the root's index.txt and we'll also use the root's OpenSSL Config file openssl_root.cnf . \n # openssl ca -config openssl_root.cnf -extensions v3_intermediate_ca -days 3600 -md sha384 -in intermediate/csr/int.cheese.csr -out intermediate/certs/int.cheese.crt.pem\n\nUsing configuration from openssl_root.cnf\nEnter pass phrase for /root/ca/private/ca.cheese.key.pem:\nCheck that the request matches the signature\nSignature ok\nCertificate Details:\n Serial Number: 4097 (0x1001)\n Validity\n Not Before: Aug 24 21:51:07 2017 GMT\n Not After : Jul 3 21:51:07 2027 GMT\n Subject:\n countryName = US\n stateOrProvinceName = WA\n organizationName = Grilled Cheese Inc.\n organizationalUnitName = Grilled Cheese Intermediary CA\n commonName = Grilled Cheese Inc. Intermediary Certificate Authority\n emailAddress = grilledcheese@yummyinmytummy.us\n X509v3 extensions:\n X509v3 Subject Key Identifier:\n 7E:2D:A5:D0:9B:70:B9:E3:D2:F7:C0:0A:CF:70:9A:8B:80:38:B1:CD\n X509v3 Authority Key Identifier:\n keyid:27:C8:F7:34:2F:30:81:97:DE:2E:FC:DD:E2:1D:FD:B6:8F:5A:AF:BB\n\n X509v3 Basic Constraints: critical\n CA:TRUE, pathlen:0\n X509v3 Key Usage: critical\n Digital Signature, Certificate Sign, CRL Sign\n X509v3 CRL Distribution Points:\n\n Full Name:\n URI:http://crl.grilledcheese.us/whomovedmycheese.crl\n\n Authority Information Access:\n CA Issuers - URI:http://ocsp.grilledcheese.us/cheddarcheeseroot.crt\n OCSP - URI:http://ocsp.grilledcheese.us/\n\nCertificate is to be certified until Jul 3 21:51:07 2027 GMT (3600 days)\nSign the certificate? [y/n]:y\n\n\n1 out of 1 certificate requests certified, commit? [y/n]y\nWrite out database with 1 new entries\nData Base Updated\n \n\n Validate the Certificate Contents with OpenSSL. \n # openssl x509 -noout -text -in intermediate/certs/int.cheese.crt.pem\n\nCertificate:\n Data:\n Version: 3 (0x2)\n Serial Number: 4097 (0x1001)\n Signature Algorithm: ecdsa-with-SHA384\n Issuer: C = US, ST = WA, L = Seattle, O = Grilled Cheese Inc., OU = Grilled Cheese Root CA, CN = Grilled Cheese Inc. Root Certificate Authority, emailAddress = grilledcheese@yummyinmytummy.us\n Validity\n Not Before: Aug 24 21:51:07 2017 GMT\n Not After : Jul 3 21:51:07 2027 GMT\n Subject: C = US, ST = WA, O = Grilled Cheese Inc., OU = Grilled Cheese Intermediary CA, CN = Grilled Cheese Inc. Intermediary Certificate Authority, emailAddress = grilledcheese@yummyinmytummy.us\n Subject Public Key Info:\n Public Key Algorithm: id-ecPublicKey\n Public-Key: (384 bit)\n pub:\n 04:9b:14:9a:55:6d:db:15:7f:d7:8b:fd:37:4d:ba:\n e8:50:8e:88:32:99:27:4e:20:36:25:8b:7b:ac:bb:\n 2f:d6:61:c1:5a:c8:e6:4c:98:20:3f:cf:86:3c:bf:\n f4:f3:b0:1c:1c:0b:cc:7f:e4:4b:13:59:58:a1:53:\n 87:cb:4c:17:66:04:21:01:6a:44:5f:22:31:7d:3d:\n fe:a2:e7:73:c8:77:7c:1a:f9:9c:4a:9d:e7:77:6a:\n c7:9e:3e:f0:4a:b0:37\n ASN1 OID: secp384r1\n NIST CURVE: P-384\n X509v3 extensions:\n X509v3 Subject Key Identifier:\n 7E:2D:A5:D0:9B:70:B9:E3:D2:F7:C0:0A:CF:70:9A:8B:80:38:B1:CD\n X509v3 Authority Key Identifier:\n keyid:27:C8:F7:34:2F:30:81:97:DE:2E:FC:DD:E2:1D:FD:B6:8F:5A:AF:BB\n\n X509v3 Basic Constraints: critical\n CA:TRUE, pathlen:0\n X509v3 Key Usage: critical\n Digital Signature, Certificate Sign, CRL Sign\n X509v3 CRL Distribution Points:\n\n Full Name:\n URI:http://crl.grilledcheese.us/whomovedmycheese.crl\n\n Authority Information Access:\n CA Issuers - URI:http://ocsp.grilledcheese.us/cheddarcheeseroot.crt\n OCSP - URI:http://ocsp.grilledcheese.us/\n\n Signature Algorithm: ecdsa-with-SHA384\n 30:65:02:30:74:07:ba:fe:4b:71:78:d8:d2:7f:84:c0:50:b4:\n b6:df:6c:f6:57:f5:d9:2c:4b:e1:d4:d8:1d:78:fd:7e:bf:0a:\n 81:86:bb:40:c5:9b:97:6f:83:04:5f:d3:85:36:6c:d6:02:31:\n 00:d3:08:78:1c:da:6d:ef:1d:bb:27:df:0b:76:eb:ab:84:b2:\n 91:04:25:1a:85:5b:d5:c3:cd:66:e4:9e:14:b2:c0:ed:9c:59:\n b7:18:c3:26:eb:df:78:13:68:47:66:b5:43\n \n\n Similar to the root, we can note the usage and algorithms but we have the addition of: \n * X509v3 CRL Distribution Points:\n Full Name:\n URI:http://crl.grilledcheese.us/whomovedmycheese.crl\n*Authority Information Access:\n CA Issuers - URI:http://ocsp.grilledcheese.us/cheddarcheeseroot.crt\n OCSP - URI:http://ocsp.grilledcheese.us/\n \n Create the certificate chain \n The root certificate and intermediary certificate must be available to the requesting client/server in order to validate the chain of trust. To complete the trust validation, a certificate chain must be available to the client application. A certificate chain usually takes the form of separate certificates installed into Root and Intermediary containers (as the case for Windows), or bundled together either in a .pfx cert and cert chain bundle or a PEM formatted text file. Concatenate the root and intermediate certificates together to create a PEM certificate chain text file. \n # cd /root/ca\n# $cat intermediate/certs/int.cheese.crt.pem certs/ca.cheese.crt.pem > intermediate/certs/chain.cheese.crt.pem\n \n The file should look similar to this with two separate BEGIN and END statements for each certificate (example condensed for space): \n # cat intermediate/certs/chain.cheese.crt.pem\n-----BEGIN CERTIFICATE-----\nMIID/TCCA4OgAwIBAgICEAEwCgYIKoZIzj0EAwMwgdQxCzAJBgNVBAYTAlVTMQsw\nCQYDVQQIDAJXQTEQMA4GA1UEBwwHU2VhdHRsZTEcMBoGA1UECgwTR3JpbGxlZCBD\n......\nhkjOPQQDAwNoADBlAjB0B7r+S3F42NJ/hMBQtLbfbPZX9dksS+HU2B14/X6/CoGG\nu0DFm5dvgwRf04U2bNYCMQDTCHgc2m3vHbsn3wt266uEspEEJRqFW9XDzWbknhSy\nwO2cWbcYwybr33gTaEdmtUM=\n-----END CERTIFICATE-----\n-----BEGIN CERTIFICATE-----\nMIIDQTCCAsegAwIBAgIJAP+99S/FDT0CMAoGCCqGSM49BAMDMIHUMQswCQYDVQQG\nEwJVUzELMAkGA1UECAwCV0ExEDAOBgNVBAcMB1NlYXR0bGUxHDAaBgNVBAoME0dy\n......\nCgYIKoZIzj0EAwMDaAAwZQIwd6H54qs6WkvOjWouMD8Bz4523fYfA9mzXKE9bTYE\n+wH3MycDhd4kVhfJGuQ7NcSoAjEAzQ5s4NUm0/uIVvpnn+m+tI+UHCy3dBnO7BXS\n/kiTCl//67LTrlpoh9zJLFSNBGh/\n-----END CERTIFICATE-----\n \n Note: In the real world hosting application should never have the entire chain available as it defeats a core principle of PKI. It's recommended in test labs to distribute the root certificate to all testing client applications and systems and include only the intermediary along with the server certificate. This way the client can establish the trust between the intermediary and root certificates. Next we'll move on to creating our CLR endpoint list and OCSP certificate. \n Our intermediary certificate is now created and signed and we are ready to move on. To complete the CA our next article we will create our certificate revocation list (CRL) endpoint and online certificate status protocol (OCSP) certificate allowing us to revoke certificates. Lab environments rarely need revocation functionality but modern clients check for CLR and OCSP URIs so it's nessisary to have the configruation defined at minimum. Let's proceed. ","body@stripHtml({\"removeProcessingText\":true,\"removeSpoilerMarkup\":true,\"removeTocMarkup\":true,\"truncateLength\":-1})@stringLength":"12835","kudosSumWeight":0,"repliesCount":2,"readOnly":false,"images":{"__typename":"AssociatedImageConnection","edges":[],"totalCount":0,"pageInfo":{"__typename":"PageInfo","hasNextPage":false,"endCursor":null,"hasPreviousPage":false,"startCursor":null}},"videos":{"__typename":"VideoConnection","edges":[],"totalCount":0,"pageInfo":{"__typename":"PageInfo","hasNextPage":false,"endCursor":null,"hasPreviousPage":false,"startCursor":null}}},"Conversation:conversation:290792":{"__typename":"Conversation","id":"conversation:290792","topic":{"__typename":"TkbTopicMessage","uid":290792},"lastPostingActivityTime":"2023-11-21T06:31:39.375-08:00","solved":false},"User:user:321467":{"__typename":"User","uid":321467,"login":"Yossi_Rosenboi1","registrationData":{"__typename":"RegistrationData","status":null},"deleted":false,"avatar":{"__typename":"UserAvatar","url":"https://community.f5.com/t5/s/zihoc95639/m_assets/avatars/default/avatar-4.svg?time=0"},"id":"user:321467"},"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yOTA3OTItMTQwOTBpN0ZCNkI4OTZBNEY1NDVFMg?revision=1\"}":{"__typename":"AssociatedImage","url":"https://community.f5.com/t5/s/zihoc95639/images/bS0yOTA3OTItMTQwOTBpN0ZCNkI4OTZBNEY1NDVFMg?revision=1","title":"0151T0000040jBFQAY.png","associationType":"BODY","width":3201,"height":1536,"altText":null},"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yOTA3OTItMTE5ODNpQjgzQTM4OTJCREZERDBGOA?revision=1\"}":{"__typename":"AssociatedImage","url":"https://community.f5.com/t5/s/zihoc95639/images/bS0yOTA3OTItMTE5ODNpQjgzQTM4OTJCREZERDBGOA?revision=1","title":"0151T0000040j9sQAA.png","associationType":"BODY","width":1771,"height":672,"altText":null},"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yOTA3OTItODM2N2k0QjJBODg3Qzg4MUI4NTE5?revision=1\"}":{"__typename":"AssociatedImage","url":"https://community.f5.com/t5/s/zihoc95639/images/bS0yOTA3OTItODM2N2k0QjJBODg3Qzg4MUI4NTE5?revision=1","title":"0151T0000040jBPQAY.png","associationType":"BODY","width":2664,"height":1479,"altText":null},"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yOTA3OTItMjYwOWk1OTk2M0JFN0RCQTA4M0Q3?revision=1\"}":{"__typename":"AssociatedImage","url":"https://community.f5.com/t5/s/zihoc95639/images/bS0yOTA3OTItMjYwOWk1OTk2M0JFN0RCQTA4M0Q3?revision=1","title":"0151T0000040jBZQAY.png","associationType":"BODY","width":5161,"height":3715,"altText":null},"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yOTA3OTItMTU4MDJpNkY2MTMyMjE1NEY5MjcwNg?revision=1\"}":{"__typename":"AssociatedImage","url":"https://community.f5.com/t5/s/zihoc95639/images/bS0yOTA3OTItMTU4MDJpNkY2MTMyMjE1NEY5MjcwNg?revision=1","title":"0151T0000040jBjQAI.png","associationType":"BODY","width":5838,"height":2988,"altText":null},"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yOTA3OTItMTI4MDhpRkFFNTkzN0FENTZBRjE0Mw?revision=1\"}":{"__typename":"AssociatedImage","url":"https://community.f5.com/t5/s/zihoc95639/images/bS0yOTA3OTItMTI4MDhpRkFFNTkzN0FENTZBRjE0Mw?revision=1","title":"0151T0000040jBoQAI.png","associationType":"BODY","width":4628,"height":2981,"altText":null},"TkbTopicMessage:message:290792":{"__typename":"TkbTopicMessage","subject":"Ingress/Egress VPC inspection with BIG-IP and GWLB","conversation":{"__ref":"Conversation:conversation:290792"},"id":"message:290792","revisionNum":1,"uid":290792,"depth":0,"board":{"__ref":"Tkb:board:TechnicalArticles"},"author":{"__ref":"User:user:321467"},"teaser@stripHtml({\"removeProcessingText\":true,\"truncateLength\":-1})":"","introduction":"","metrics":{"__typename":"MessageMetrics","views":1631},"postTime":"2021-08-03T08:09:49.000-07:00","lastPublishTime":"2021-08-03T08:09:49.000-07:00","body@stripHtml({\"removeProcessingText\":true,\"removeSpoilerMarkup\":true,\"removeTocMarkup\":true,\"truncateLength\":-1})":" Introduction The previous article in this series reviewed the BIG-IP and AWS Gateway Load Balancer (GWLB) integration, in this article we will focus on a deployment pattern that is used to inspect traffic in and out of a VPC using BIG-IP security services and GWLB. Baseline: In this scenario we will focus on a single existing VPC with EC2 instances and no BIG-IP security services Goal: Inspect traffic in and out of the VPC, scale the BIG-IP deployment as needed Deployment pattern: Considering the requirements and tools available, the deployment pattern will use the following attributes: Separate the security devices (BIG-IP's) from the workloads they are protecting. The BIG-IP's will be deployed in their own VPC – the Security VPC. We will reference the workload VPC as the 'Consumer' VPC as it consumes security services. Use Routing tables in the 'consumer' VPC to send all traffic to the security VPC for inspection. Leverage transparent security services on the BIG-IP for inspection (BIG-IP security features configuration is out of scope for this article) We can dive into each of the individual tasks: The Security VPC Provisioning the 'consumer' VPC network to send traffic through the security VPC Security VPC: Here, we are deploying the BIG-IP fleet and exposing it using GWLB. Some of the considerations when creating this VPC: Deploy in the same region as the 'consumer' VPC Design based on your availability requirements, Number of availability zones(AZ) How many BIG-IP's in each AZ These are the actions we need to take in the provider VPC to inspect all ingress/egress traffic: Deploy a group of BIG-IP's Create a GWLB target group and associate the BIG-IP's to it Create a GWLB and assign the previously created target group to the listener Create a GWLB endpoint service and associate it with the GWLB Configure the BIG-IP's to receive traffic over the tunnel and inspect according to the desired policy Diagram: The security VPC - BIG-IP fleet behind a GWLB, exposed using GWLB service Consumer VPC: In the consumer VPC, the BIG-IP group is abstracted by the GWLB and consumes the security services from the provider VPC via a new component: GWLB endpoint. This endpoint acts as bridge between the consumer VPC and the provider VPC. It essentially creates an ENI in one of the consumer's VPC subnet. Please note that a single endpoint belongs to a single availability zone and design accordingly. Inspecting all ingress traffic requires the use of 'Ingress routing' – an AWS feature that allows sending all ingress traffic from the internet gateway to an ENI or to a GWLB endpoint. Here are the actions we need to take in the consumer VPC to inspect all ingress/egress traffic: Create GWLB endpoints in each relevant availability zone that are attached to the 'GWLB endpoint service' from the provider VPC Change the ingress routing table so that all traffic in each AZ will get routed to the respective GWLB endpoint. Change the subnets routing tables so that all traffic in each AZ will get routed to the respective GWLB endpoint. Diagram: Inspecting all ingress/egress in the Security provider VPC Traffic flow Ingress traffic flow between an external user and an EC2 instance in the consumer VPC: Egress traffic flow between an EC2 instance in the consumer VPC and an external user: Summary: With this deployment you can protect your AWS VPC using the robust security services offered by the BIG-IP platform and get the following benefits: Scalability - Deploy as many BIG-IP instances as you need based on performance and availability requirements Transparent inspection - Inspecting the traffic without any address translation Optimized compute - all BIG-IP devices are active and processing traffic Next steps: Test the deployment yourself - Check out our self-service lab that you can deploy in your own AWS account (Fully automated deployment using Terraform): https://github.com/f5devcentral/f5-digital-customer-engagement-center/tree/main/solutions/security/ingress-egress-fw ","body@stripHtml({\"removeProcessingText\":true,\"removeSpoilerMarkup\":true,\"removeTocMarkup\":true,\"truncateLength\":-1})@stringLength":"4257","kudosSumWeight":2,"repliesCount":1,"readOnly":false,"images":{"__typename":"AssociatedImageConnection","edges":[{"__typename":"AssociatedImageEdge","cursor":"MjUuMnwyLjF8b3wyNXxfTlZffDE","node":{"__ref":"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yOTA3OTItMTQwOTBpN0ZCNkI4OTZBNEY1NDVFMg?revision=1\"}"}},{"__typename":"AssociatedImageEdge","cursor":"MjUuMnwyLjF8b3wyNXxfTlZffDI","node":{"__ref":"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yOTA3OTItMTE5ODNpQjgzQTM4OTJCREZERDBGOA?revision=1\"}"}},{"__typename":"AssociatedImageEdge","cursor":"MjUuMnwyLjF8b3wyNXxfTlZffDM","node":{"__ref":"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yOTA3OTItODM2N2k0QjJBODg3Qzg4MUI4NTE5?revision=1\"}"}},{"__typename":"AssociatedImageEdge","cursor":"MjUuMnwyLjF8b3wyNXxfTlZffDQ","node":{"__ref":"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yOTA3OTItMjYwOWk1OTk2M0JFN0RCQTA4M0Q3?revision=1\"}"}},{"__typename":"AssociatedImageEdge","cursor":"MjUuMnwyLjF8b3wyNXxfTlZffDU","node":{"__ref":"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yOTA3OTItMTU4MDJpNkY2MTMyMjE1NEY5MjcwNg?revision=1\"}"}},{"__typename":"AssociatedImageEdge","cursor":"MjUuMnwyLjF8b3wyNXxfTlZffDY","node":{"__ref":"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yOTA3OTItMTI4MDhpRkFFNTkzN0FENTZBRjE0Mw?revision=1\"}"}}],"totalCount":6,"pageInfo":{"__typename":"PageInfo","hasNextPage":false,"endCursor":null,"hasPreviousPage":false,"startCursor":null}},"videos":{"__typename":"VideoConnection","edges":[],"totalCount":0,"pageInfo":{"__typename":"PageInfo","hasNextPage":false,"endCursor":null,"hasPreviousPage":false,"startCursor":null}}},"Conversation:conversation:291221":{"__typename":"Conversation","id":"conversation:291221","topic":{"__typename":"TkbTopicMessage","uid":291221},"lastPostingActivityTime":"2023-09-07T08:24:55.936-07:00","solved":false},"User:user:242856":{"__typename":"User","uid":242856,"login":"MichaelOLeary","registrationData":{"__typename":"RegistrationData","status":null},"deleted":false,"avatar":{"__typename":"UserAvatar","url":"https://community.f5.com/t5/s/zihoc95639/images/dS0yNDI4NTYtMjA2NzVpMjAwQzU1OUQzMEFFMDM2RQ"},"id":"user:242856"},"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yOTEyMjEtNjk3M2k0NDMwQUU4RjVBNDgyM0Ez?revision=1\"}":{"__typename":"AssociatedImage","url":"https://community.f5.com/t5/s/zihoc95639/images/bS0yOTEyMjEtNjk3M2k0NDMwQUU4RjVBNDgyM0Ez?revision=1","title":"0151T000003d7JkQAI.JPG","associationType":"BODY","width":1226,"height":873,"altText":null},"TkbTopicMessage:message:291221":{"__typename":"TkbTopicMessage","subject":"Deploy BIG-IP in AWS with HA across AZ’s - without using EIP’s","conversation":{"__ref":"Conversation:conversation:291221"},"id":"message:291221","revisionNum":1,"uid":291221,"depth":0,"board":{"__ref":"Tkb:board:TechnicalArticles"},"author":{"__ref":"User:user:242856"},"teaser@stripHtml({\"removeProcessingText\":true,\"truncateLength\":-1})":"","introduction":"","metrics":{"__typename":"MessageMetrics","views":8426},"postTime":"2019-02-21T05:00:00.000-08:00","lastPublishTime":"2019-02-21T05:00:00.000-08:00","body@stripHtml({\"removeProcessingText\":true,\"removeSpoilerMarkup\":true,\"removeTocMarkup\":true,\"truncateLength\":-1})":" Background: \n\n The CloudFormation templates that are provided and supported by F5 are an excellent resource for customers to deploy BIG-IP VE in AWS. Along with these templates, documentation guiding your F5 deployment in AWS is an excellent resource. \n\n And of course, DevCentral articles are helpful. I recommend reading about HA topologies in AWS to start. I hope my article today can shed more light on an architecture that will suit a specific set of requirements: No Elastic IP's (EIP’s), High Availability (HA) across AZ’s, and multiple VPC’s. \n\n Requirements behind this architecture choice: \n\n I recently had a requirement to deploy BIG-IP appliances in AWS across AZ’s. I had read the official deployment guide, but I wasn’t clear on how to achieve failover without EIP’s. I was given 3 requirements: \n\n HA across AZ’s. In this architecture, we required a pair of BIG-IP devices in Active/Standby, where each device was in a different AZ. I needed to be able to fail over between devices. No EIP’s. This requirement existed because a 3 rd party firewall was already exposed to the Internet with a public IP address. That firewall would forward inbound requests to the BIG-IP VE in AWS, which in turn proxied traffic to a pair of web servers. Therefore, there was no reason to associate an EIP (a public IP address) with the BIG-IP interface. In my demo below I have not exposed a public website through a 3 rd party firewall, but to do so is a simple addition to this demo environment. Multiple VPC’s. This architecture had to allow for multiple VPC’s in AWS. There was already a “Security VPC” which contained firewalls, BIG-IP devices, and other devices, and I had to be able to use these devices for protecting applications that were across 1 or more disparate VPC’s. \n\n Meeting the requirements: \n\n HA across AZ’s \n\n This is the easiest of the requirements to meet because F5 has already provided templates to deploy these in AWS. I personally used a 2-nic device, with a BYOL license, deployed to an existing VPC, so that meant my template was this one. After this deployment is complete, you should have a pair of devices that will sync their configuration. \n\n At time of failover\n The supported F5 templates will deploy with the Advanced HA iApp. It is important that you configure this iApp after you have completed your AWS deployments. The iApp uses IAM permissions deployed with the template to make API calls to AWS at the time of failover. The API calls will update the route tables that you specify within the iApp wizard. Because this iApp is installed on both devices, either device can update the route in your route tables to point to its own interface. Update as of Dec 2019 This article was first written Feb 2019, and in Dec 2019 F5 released the Cloud Failover Extension (CFE), which is a cloud-agnostic, declarative way to configure failover in multiple public clouds. You can use the CFE instead of the Advanced HA iApp to achieve high availability between BIG-IP devices in cloud. Update as of Apr 2020 Your API calls will typically be sent to the public Internet endpoints for AWS EC2 API calls. Optionally, you can use AWS VPC endpoints to keep your API calls out to AWS EC2 from traversing the public Internet. My colleague Arnulfo Hernandez has written an article explaining how to do this. \n\n No EIP’s \n\n Configure an “alien IP range” \n\n I’m recycling another DevCentral solution here. You will need to choose an IP range for your VIP network that does not fall within the CIDR that is assigned to your VPC. Let’s call it an “alien range” because it “doesn’t belong” in your VPC and you couldn’t assign IP addresses from this range to your AWS ENI’s. Despite that, now create a route table within AWS that points this “alien range” to your Active BIG-IP device’s ENI (if you’re using a 2+ nic device, point it to the correct data plane NIC, not the Mgmt. interface). Don’t forget to associate the route table with specific subnets, per your design. Alternatively, you could add this route to the default VPC route table. \n\n Create a VIP on your active device \n\n Now create a VIP on your active device and configure the IP address as an IP within your alien range. Ensure the config replicates to your standby device. Ensure that source/destination checking is disabled on the ENI’s that your AWS routes are pointing to (on both Standby and Active devices). You should now have a VIP that you can target from other hosts in your VPC, provided that the route you created above is applied to the traffic destined to the VIP. \n\n Multiple VPC’s \n\n For extra credit, we’ll set up a Transit Gateway. This will allow other VPCs to route traffic to this “alien range” also, provided that the appropriate routes exist in the remote VPC’s, and also are applied to the appropriate Transit Gateway Route Table. Again, I’m recycling ideas that have already been laid out in other DevCentral posts. \n\n I won’t re-hash how to set up a transit gateway in AWS, because you can follow the linked post above. Sufficed to say, this is what you will need to set up if you want to route between multiple VPC’s using a transit gateway: \n\n 2 or more VPC’s A transit gateway in AWS Multiple transit gateway attachments that attach the transit gateway and each VPC you would like to route between. You will need one attachment per VPC. A transit gateway route table that is associated with each attachment. \n\n \n\n I will point out that you need to add a route for your “alien range” in your transit gateway route table, and in your remote VPC’s. That way, hosts in your remote VPC’s will forward traffic destined to your alien range (VIP network) to the transit gateway, and the transit gateway will forward it to your VPC, and the route you created in Step A will forward that traffic to your active BIG-IP device. \n\n Completed design: \n\n After the above configuration, you should have an environment that looks like the diagram below: \n\n \n\n Tips \n\n Internet access for deployments: When you deploy your BIG-IP devices, they will need Internet access to pull down some resources, including the iApp. So if you are deploying devices into your existing VPC, make sure you have a reachable Internet Gateway in AWS so that the devices have Internet access through both their management interface, and their data plane interface(s). \n\n Internet access for failover: Remember that an API call to AWS will still use an outbound request to the Internet. Make sure you allow the BIG-IP devices to make outbound connections over HTTPS to the Internet. If this is not available, you will find that your route tables are not updated at time of failover. (If you have a hard requirement that your devices should not have outbound access to internet, you can follow Arnulfo's guide linked to above and use VPC endpoints to keep this traffic on your local VPC) \n\n iApp logs: you can enable this in the iApp settings. I have used the logs (in /var/ltm/log) to troubleshoot issues that I have created myself. That’s how I learned not to accidentally cut off Internet access for your devices! \n\n Don’t forget about return routes if SNAT is disabled: Just like on-prem environments, if you disable SNAT, the pool member will need to route return traffic back to the BIG-IP device. You will commonly set up a default route (0.0.0.0/0) in AWS, point it at the ENI of the active BIG-IP device, and associate this route table with the subnet containing the pool members. If the pool members are in a remote VPC, you will need to create this route on the transit gw route table also. \n\n Don’t accidentally cut off internet access: When you configure the default route of 0.0.0.0/0 to point to eth1 of the BIG-IP device, don’t apply this route to every subnet in your Security VPC. It may be easy to do so accidentally, but remember that it could cause the API calls to update route tables to fail when the Standby device becomes Active. \n\n Don’t forget to disable source/dest check on your ENI’s. This is configured by the template, but if you have other devices that require it, remember to check this setting. ","body@stripHtml({\"removeProcessingText\":true,\"removeSpoilerMarkup\":true,\"removeTocMarkup\":true,\"truncateLength\":-1})@stringLength":"8203","kudosSumWeight":5,"repliesCount":27,"readOnly":false,"images":{"__typename":"AssociatedImageConnection","edges":[{"__typename":"AssociatedImageEdge","cursor":"MjUuMnwyLjF8b3wyNXxfTlZffDE","node":{"__ref":"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yOTEyMjEtNjk3M2k0NDMwQUU4RjVBNDgyM0Ez?revision=1\"}"}}],"totalCount":1,"pageInfo":{"__typename":"PageInfo","hasNextPage":false,"endCursor":null,"hasPreviousPage":false,"startCursor":null}},"videos":{"__typename":"VideoConnection","edges":[],"totalCount":0,"pageInfo":{"__typename":"PageInfo","hasNextPage":false,"endCursor":null,"hasPreviousPage":false,"startCursor":null}}},"Conversation:conversation:276612":{"__typename":"Conversation","id":"conversation:276612","topic":{"__typename":"TkbTopicMessage","uid":276612},"lastPostingActivityTime":"2023-07-24T09:26:46.666-07:00","solved":false},"User:user:173160":{"__typename":"User","uid":173160,"login":"ChrisMutzel_151","registrationData":{"__typename":"RegistrationData","status":null},"deleted":false,"avatar":{"__typename":"UserAvatar","url":"https://community.f5.com/t5/s/zihoc95639/m_assets/avatars/default/avatar-3.svg?time=0"},"id":"user:173160"},"TkbTopicMessage:message:276612":{"__typename":"TkbTopicMessage","subject":"F5 in AWS Part 4 - Orchestrating BIG-IP Application Services with Open-Source tools","conversation":{"__ref":"Conversation:conversation:276612"},"id":"message:276612","revisionNum":2,"uid":276612,"depth":0,"board":{"__ref":"Tkb:board:TechnicalArticles"},"author":{"__ref":"User:user:173160"},"teaser@stripHtml({\"removeProcessingText\":true,\"truncateLength\":-1})":"","introduction":"","metrics":{"__typename":"MessageMetrics","views":1400},"postTime":"2015-09-29T00:01:00.000-07:00","lastPublishTime":"2023-06-05T22:23:36.514-07:00","body@stripHtml({\"removeProcessingText\":true,\"removeSpoilerMarkup\":true,\"removeTocMarkup\":true,\"truncateLength\":-1})":" Updated for Current Versions and Documentation \n\n 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 \n\n 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. \n\n Full documentation for F5 BIG-IP cloud work can be found at Cloud Docs: F5 Public Cloud Integrations. \n\n \n 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. \n\n 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. \n\n 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. \n\n Open-source configuration management and AWS APIs \n\n 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: \n\n Ansible Puppet SaltStack \n\n 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. \n\n Using Standardized BIG-IP Interfaces \n\n 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. \n\n 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. \n\n Implementing a Service Catalog \n\n 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. \n\n Some highlights of the project include: \n\n 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. \n\n \n\n Figure 1 - Generic Architecture for automating application deployments in public or private cloud \n\n 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. \n\n \n\n Figure 2 - Technologies used in the aws-deployments project on Github \n\n Read the Code and Test It Yourself \n\n 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). \n\n 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. \n\n Have fun! ","body@stripHtml({\"removeProcessingText\":true,\"removeSpoilerMarkup\":true,\"removeTocMarkup\":true,\"truncateLength\":-1})@stringLength":"7510","kudosSumWeight":1,"repliesCount":3,"readOnly":false,"images":{"__typename":"AssociatedImageConnection","edges":[],"totalCount":0,"pageInfo":{"__typename":"PageInfo","hasNextPage":false,"endCursor":null,"hasPreviousPage":false,"startCursor":null}},"videos":{"__typename":"VideoConnection","edges":[],"totalCount":0,"pageInfo":{"__typename":"PageInfo","hasNextPage":false,"endCursor":null,"hasPreviousPage":false,"startCursor":null}}},"CachedAsset:text:en_US-components/community/Navbar-1744046279002":{"__typename":"CachedAsset","id":"text:en_US-components/community/Navbar-1744046279002","value":{"community":"Community Home","inbox":"Inbox","manageContent":"Manage Content","tos":"Terms of Service","forgotPassword":"Forgot Password","themeEditor":"Theme Editor","edit":"Edit Navigation Bar","skipContent":"Skip to content","migrated-link-9":"Groups","migrated-link-7":"Technical Articles","migrated-link-8":"DevCentral News","migrated-link-1":"Technical Forum","migrated-link-10":"Community Groups","migrated-link-2":"Water Cooler","migrated-link-11":"F5 Groups","Common-external-link":"How Do I...?","migrated-link-0":"Forums","article-series":"Article Series","migrated-link-5":"Community Articles","migrated-link-6":"Articles","security-insights":"Security Insights","migrated-link-3":"CrowdSRC","migrated-link-4":"CodeShare","migrated-link-12":"Events","migrated-link-13":"Suggestions"},"localOverride":false},"CachedAsset:text:en_US-components/community/NavbarHamburgerDropdown-1744046279002":{"__typename":"CachedAsset","id":"text:en_US-components/community/NavbarHamburgerDropdown-1744046279002","value":{"hamburgerLabel":"Side Menu"},"localOverride":false},"CachedAsset:text:en_US-components/community/BrandLogo-1744046279002":{"__typename":"CachedAsset","id":"text:en_US-components/community/BrandLogo-1744046279002","value":{"logoAlt":"Khoros","themeLogoAlt":"Brand Logo"},"localOverride":false},"CachedAsset:text:en_US-components/community/NavbarTextLinks-1744046279002":{"__typename":"CachedAsset","id":"text:en_US-components/community/NavbarTextLinks-1744046279002","value":{"more":"More"},"localOverride":false},"CachedAsset:text:en_US-components/authentication/AuthenticationLink-1744046279002":{"__typename":"CachedAsset","id":"text:en_US-components/authentication/AuthenticationLink-1744046279002","value":{"title.login":"Sign In","title.registration":"Register","title.forgotPassword":"Forgot Password","title.multiAuthLogin":"Sign In"},"localOverride":false},"CachedAsset:text:en_US-components/nodes/NodeLink-1744046279002":{"__typename":"CachedAsset","id":"text:en_US-components/nodes/NodeLink-1744046279002","value":{"place":"Place {name}"},"localOverride":false},"CachedAsset:text:en_US-components/tags/TagSubscriptionAction-1744046279002":{"__typename":"CachedAsset","id":"text:en_US-components/tags/TagSubscriptionAction-1744046279002","value":{"success.follow.title":"Following Tag","success.unfollow.title":"Unfollowed Tag","success.follow.message.followAcrossCommunity":"You will be notified when this tag is used anywhere across the community","success.unfollowtag.message":"You will no longer be notified when this tag is used anywhere in this place","success.unfollowtagAcrossCommunity.message":"You will no longer be notified when this tag is used anywhere across the community","unexpected.error.title":"Error - Action Failed","unexpected.error.message":"An unidentified problem occurred during the action you took. Please try again later.","buttonTitle":"{isSubscribed, select, true {Unfollow} false {Follow} other{}}","unfollow":"Unfollow"},"localOverride":false},"CachedAsset:text:en_US-components/messages/MessageListTabs-1744046279002":{"__typename":"CachedAsset","id":"text:en_US-components/messages/MessageListTabs-1744046279002","value":{"mostKudoed":"{value, select, IDEA {Most Votes} other {Most Likes}}","mostReplies":"Most Replies","mostViewed":"Most Viewed","newest":"{value, select, IDEA {Newest Ideas} OCCASION {Newest Events} other {Newest Topics}}","newestOccasions":"Newest Events","mostRecent":"Most Recent","noReplies":"No Replies Yet","noSolutions":"No Solutions Yet","solutions":"Solutions","mostRecentUserContent":"Most Recent","trending":"Trending","draft":"Drafts","spam":"Spam","abuse":"Abuse","moderation":"Moderation","tags":"Tags","PAST":"Past","UPCOMING":"Upcoming","sortBymostRecent":"Sort By Most Recent","sortBymostRecentUserContent":"Sort By Most Recent","sortBymostKudoed":"Sort By Most Likes","sortBymostReplies":"Sort By Most Replies","sortBymostViewed":"Sort By Most Viewed","sortBynewest":"Sort By Newest Topics","sortBynewestOccasions":"Sort By Newest Events","otherTabs":" Messages list in the {tab} for {conversationStyle}","guides":"Guides","archives":"Archives"},"localOverride":false},"CachedAsset:text:en_US-shared/client/components/common/QueryHandler-1744046279002":{"__typename":"CachedAsset","id":"text:en_US-shared/client/components/common/QueryHandler-1744046279002","value":{"title":"Query Handler"},"localOverride":false},"CachedAsset:text:en_US-components/community/NavbarDropdownToggle-1744046279002":{"__typename":"CachedAsset","id":"text:en_US-components/community/NavbarDropdownToggle-1744046279002","value":{"ariaLabelClosed":"Press the down arrow to open the menu"},"localOverride":false},"CachedAsset:text:en_US-shared/client/components/common/OverflowNav-1744046279002":{"__typename":"CachedAsset","id":"text:en_US-shared/client/components/common/OverflowNav-1744046279002","value":{"toggleText":"More"},"localOverride":false},"CachedAsset:text:en_US-components/messages/MessageView/MessageViewInline-1744046279002":{"__typename":"CachedAsset","id":"text:en_US-components/messages/MessageView/MessageViewInline-1744046279002","value":{"bylineAuthor":"{bylineAuthor}","bylineBoard":"{bylineBoard}","anonymous":"Anonymous","place":"Place {bylineBoard}","gotoParent":"Go to parent {name}"},"localOverride":false},"CachedAsset:text:en_US-shared/client/components/common/Pager/PagerLoadMore-1744046279002":{"__typename":"CachedAsset","id":"text:en_US-shared/client/components/common/Pager/PagerLoadMore-1744046279002","value":{"loadMore":"Show More"},"localOverride":false},"CachedAsset:text:en_US-components/customComponent/CustomComponent-1744046279002":{"__typename":"CachedAsset","id":"text:en_US-components/customComponent/CustomComponent-1744046279002","value":{"errorMessage":"Error rendering component id: {customComponentId}","bannerTitle":"Video provider requires cookies to play the video. Accept to continue or {url} it directly on the provider's site.","buttonTitle":"Accept","urlText":"watch"},"localOverride":false},"CachedAsset:text:en_US-components/users/UserLink-1744046279002":{"__typename":"CachedAsset","id":"text:en_US-components/users/UserLink-1744046279002","value":{"authorName":"View Profile: {author}","anonymous":"Anonymous"},"localOverride":false},"CachedAsset:text:en_US-components/messages/MessageSubject-1744046279002":{"__typename":"CachedAsset","id":"text:en_US-components/messages/MessageSubject-1744046279002","value":{"noSubject":"(no subject)"},"localOverride":false},"CachedAsset:text:en_US-components/messages/MessageTime-1744046279002":{"__typename":"CachedAsset","id":"text:en_US-components/messages/MessageTime-1744046279002","value":{"postTime":"Published: {time}","lastPublishTime":"Last Update: {time}","conversation.lastPostingActivityTime":"Last posting activity time: {time}","conversation.lastPostTime":"Last post time: {time}","moderationData.rejectTime":"Rejected time: {time}"},"localOverride":false},"CachedAsset:text:en_US-shared/client/components/nodes/NodeIcon-1744046279002":{"__typename":"CachedAsset","id":"text:en_US-shared/client/components/nodes/NodeIcon-1744046279002","value":{"contentType":"Content Type {style, select, FORUM {Forum} BLOG {Blog} TKB {Knowledge Base} IDEA {Ideas} OCCASION {Events} other {}} icon"},"localOverride":false},"CachedAsset:text:en_US-components/messages/MessageUnreadCount-1744046279002":{"__typename":"CachedAsset","id":"text:en_US-components/messages/MessageUnreadCount-1744046279002","value":{"unread":"{count} unread","comments":"{count, plural, one { unread comment} other{ unread comments}}"},"localOverride":false},"CachedAsset:text:en_US-components/messages/MessageViewCount-1744046279002":{"__typename":"CachedAsset","id":"text:en_US-components/messages/MessageViewCount-1744046279002","value":{"textTitle":"{count, plural,one {View} other{Views}}","views":"{count, plural, one{View} other{Views}}"},"localOverride":false},"CachedAsset:text:en_US-components/kudos/KudosCount-1744046279002":{"__typename":"CachedAsset","id":"text:en_US-components/kudos/KudosCount-1744046279002","value":{"textTitle":"{count, plural,one {{messageType, select, IDEA{Vote} other{Like}}} other{{messageType, select, IDEA{Votes} other{Likes}}}}","likes":"{count, plural, one{like} other{likes}}"},"localOverride":false},"CachedAsset:text:en_US-components/messages/MessageRepliesCount-1744046279002":{"__typename":"CachedAsset","id":"text:en_US-components/messages/MessageRepliesCount-1744046279002","value":{"textTitle":"{count, plural,one {{conversationStyle, select, IDEA{Comment} OCCASION{Comment} other{Reply}}} other{{conversationStyle, select, IDEA{Comments} OCCASION{Comments} other{Replies}}}}","comments":"{count, plural, one{Comment} other{Comments}}"},"localOverride":false},"CachedAsset:text:en_US-components/messages/MessageBody-1744046279002":{"__typename":"CachedAsset","id":"text:en_US-components/messages/MessageBody-1744046279002","value":{"showMessageBody":"Show More","mentionsErrorTitle":"{mentionsType, select, board {Board} user {User} message {Message} other {}} No Longer Available","mentionsErrorMessage":"The {mentionsType} you are trying to view has been removed from the community.","videoProcessing":"Video is being processed. Please try again in a few minutes.","bannerTitle":"Video provider requires cookies to play the video. Accept to continue or {url} it directly on the provider's site.","buttonTitle":"Accept","urlText":"watch"},"localOverride":false},"CachedAsset:text:en_US-shared/client/components/users/UserAvatar-1744046279002":{"__typename":"CachedAsset","id":"text:en_US-shared/client/components/users/UserAvatar-1744046279002","value":{"altText":"{login}'s avatar","altTextGeneric":"User's avatar"},"localOverride":false}}}},"page":"/tags/TagPage/TagPage","query":{"nodeId":"category:Articles","tagName":"AWS"},"buildId":"q_bLpq2mflH0BeZigxpj6","runtimeConfig":{"buildInformationVisible":false,"logLevelApp":"info","logLevelMetrics":"info","openTelemetryClientEnabled":false,"openTelemetryConfigName":"f5","openTelemetryServiceVersion":"25.2.0","openTelemetryUniverse":"prod","openTelemetryCollector":"http://localhost:4318","openTelemetryRouteChangeAllowedTime":"5000","apolloDevToolsEnabled":false,"inboxMuteWipFeatureEnabled":false},"isFallback":false,"isExperimentalCompile":false,"dynamicIds":["./components/customComponent/CustomComponent/CustomComponent.tsx","./components/community/Navbar/NavbarWidget.tsx","./components/community/Breadcrumb/BreadcrumbWidget.tsx","./components/tags/TagsHeaderWidget/TagsHeaderWidget.tsx","./components/messages/MessageListForNodeByRecentActivityWidget/MessageListForNodeByRecentActivityWidget.tsx","./components/tags/TagSubscriptionAction/TagSubscriptionAction.tsx","./components/customComponent/CustomComponentContent/TemplateContent.tsx","../shared/client/components/common/List/ListGroup/ListGroup.tsx","./components/messages/MessageView/MessageView.tsx","./components/messages/MessageView/MessageViewInline/MessageViewInline.tsx","../shared/client/components/common/Pager/PagerLoadMore/PagerLoadMore.tsx","./components/customComponent/CustomComponentContent/HtmlContent.tsx","./components/customComponent/CustomComponentContent/CustomComponentScripts.tsx"],"appGip":true,"scriptLoader":[]}