Archive for aws

Automatically Update your BIG-IP Pool Using the Service Discovery iApp

Posted in f5, big-ip, cloud computing, iApps, aws, azure by psilva on September 12th, 2017

Let’s look at how to automatically add members to your BIG-IP pool by using the Service Discovery iApp. Whenever you deploy a BIG-IP Virtual Edition by using one of the templates on the F5 Github site, this iApp is installed on the BIG-IP.

The idea behind this iApp is you assign a tag to a virtual machine in the cloud and then BIG-IP automatically discovers it and adds it to the pool. By tagging instances in AWS and Azure, and configuring the iApp, the pool is updated based on an interval you specify. This is especially helpful if you auto-scale your application servers because they are then automatically added and removed.

sdi1.jpg

Today, we’ll look how to do this in Azure but you can also do this in AWS.

First, we’re going to add a tag to the application sever in Azure. You can assign the tag to either the virtual machine or to the NIC. For auto-scaling you’d tag the scale set. This can we’ll simply add it to the virtual machine.

sdi2.jpg

When you click through the virtual machine, on the left you’ll get the ‘Tags’ option.

sdi3.jpg

This entry can be any name/value pair you want and for this we’ll use ‘mytag’ and ‘addme.’

sdi4.jpg

And we’ll click Save.

sdi5.jpg

For this exercise, we have two application servers in the resource group and already added the tags for that one. So at this point, we’re ready to get into the BIG-IP and configure the iApp.

Once in, go to Application Services>Applications>Create.

sdi6.jpg

Next, we give it a name and choose f5_service_discovery from the list.

sdi7.jpg

Scroll down the same page and fill out the open fields. Under Cloud Provider, we select Azure. Depending on your provider, there are additional questions. Add the Azure resource group and the Subscription ID. The next 3 fields (for the Azure selection) are security related: Tenant ID, Client ID and Service Principal Secret. Rather than using your own credentials to create and modify resources in Azure, you can create an Azure Active Directory application and assign permissions to that. Details are included on the Github ReadMe or the Azure documentation about service Principal.

Under the Pool area, is where you enter the name/value pair that we used for the tags in Azure. We leave the rest default. In this instance, you may notice the update interval at 60 seconds. By default, 60 seconds is the interval that BIG-IP will query Azure to see if there is a resource with the tags you specified. Under Application Health, select ‘http’ as the health monitor. Click Finished.

sdi8.jpg

When complete, we can see we got a pool with two active members in it.

sdi9.jpg

If you take the tags off one of the instances, it’ll leave the pool. Of note however, there must be two members in the pool before you remove tags from an instance. If you remove the tags from all the application servers, the pool will not be updated. BIG-IP must see at least one set of tags to update the pool because it doesn’t want to leave you with an empty pool.

Here’s the before and after of removing a tag.

sdi9ab.jpg

One final note. This example configuration has the BIG-IP in one resource group and the application servers in another resource group but they are all on the same Vnet. If you have separate networks in Azure, you’ll need to create a peering so they can communicate. Similarly, in AWS, you need to make sure the networking is set up so the BIG-IP can see the application servers. But, once the initial set up is working, there’s no manual intervention required.

You can use the Service Discovery method to add and remove application servers all day long without having to manually update the BIG-IP. Again, and as always, thanks to our Technical Communications team for the great material and watch the video demo here.

ps

Related:




Deploy an Auto-Scaled BIG-IP VE WAF in AWS

Posted in security, f5, big-ip, application security, cloud, privacy, waf, aws by psilva on August 29th, 2017

Today let’s look at how to create and deploy an auto-scaled BIG-IP Virtual Edition Web Application Firewall by using a Cloud Formation Template (CFT) in AWS. CFTs are simply a quick way to spin up solutions that otherwise, you may have to create manually. The idea behind this CFT is it is going to create BIG-IP VE instances for you. These instances function as a firewall in front of your application. Depending on the limits you specify, when more traffic is going to your application, new instances will launch…and when there is less traffic, instances will terminate.

awaf1.jpg

This solution has a few prerequisites:

  • A Virtual Private Cloud (VPC) with at least two subnets, each in its own availability zone
  • An AWS Elastic Load Balancer (ELB), which serves traffic to the BIG-IP VE instances
  • An SSH key pair which you need to access the instances.

I have these already created, so we’ll proceed to deploying the template.

You have two choices on how you want to deploy. You can go to the AWS Marketplace and search ‘f5 waf’ or you can go to the F5 Networks GitHub site. GitHub usually has the latest and greatest, so we’ll use that.

Click on the f5-aws-cloudformation spot.

awaf2.jpg

And then click Supported.

awaf3.jpg

And then click solutions/autoscale.

awaf4.jpg

Then waf.

awaf5.jpg

We scroll down a little bit and click Launch Stack.

awaf6.jpg

We click Next at the Select Template screen and fill out the template.

awaf7.jpg

When you get to the template, the Deployment Name will be appended to all the instances so you can tell which ones are yours. Since we already set up a VPC with two subnets in two zones (not regions), we’ll select those in the VPC ID field. The Restricted Source Address is available if you only want to allow specific IP addresses to your BIG-IP VE instances.

awaf8.jpg

Next is the AWS Elastic Load Balancer name, then choose your SSH key – which is needed to connect to the instances. And we’ll leave the defaults for the rest.

awaf9.jpg

Then you’ll get to the Auto Scaling Configuration section which is where you’ll determine when to create the new WAF instances. You’ll want to configure the Scale Up & Scale Down Bytes Threshold which will, obviously, determine when one gets launched/added and when it is removed.

awaf9a.jpg

Under WAF Virtual Service Configuration, is where you’ll enter the application’s Service Port and DNS. In addition, if you wanted to automatically add application servers to the pool to have traffic will go to those without having to manually configure the BIG-IP, you can also add the Application Pool Tag Values which works great. Next choose your WAF Policy Level (low, medium, high) and click Next and Next.

awaf9b.jpg

Also, click the check box with indicates that you have the appropriate credentials to set some IAM roles and create a S3 Bucket. Click Create and the CFT will start creating resources.

awaf9c.jpg

This process can take about 15 minutes to complete and when it is done, you’ll get the CREATE_COMPLETE on your dashboard. The resources might be available right away but it is recommended to wait at least 30 minutes before digging into things.

awaf9d.jpg

To see what the CFT created and confirm completion, go to: Services>EC2>Auto Scaling Groups. You can see that there is a BIG-IP VE instance created and added to the group. Also, be aware that the default for Scaling Policies is to wait 40 minutes to launch a new instance. You may want to adjust that to your preference. However, to be clear, AWS is always monitoring the traffic and want to know if you are exceeding the limits you’ve set. The Scaling Policies setting simply means that after one instance is launched – you hit the limit and one is up – AWS should wait 40 minutes (or whatever your value is) to launch another. It’ll keep going until you’ve hit the max number of instances specified. We put three.

awaf9e.jpg

While in Services>EC2, you can also inspect the ELB and see that the BIG-IP VE instance is there and in service. Traffic is going through the Load Balancer and then to the BIG-IP VE, then to the application server.

awaf9f.jpg

Lastly, let’s look at the list of instances in Services>EC2>Instances and the instances are there and ready to go!

awaf9g.jpg

And then when there is too much traffic, another is added. Since the limit was exceeded, AWS has launched new instances, up to three.

awaf9h.jpg

And when the traffic falls, the instance shuts down.

awaf9i.jpg

That’s it! Easily scale your BIG-IP application security on AWS. Thanks to our TechPubs group and watch the video demo here.

ps

 




Cloud Month on DevCentral

Posted in f5, big-ip, cloud, cloud computing, application delivery, devcentral, aws, azure by psilva on June 1st, 2017

 

#DCCloud17

dc-logo.jpgThe term ‘Cloud’ as in Cloud Computing has been around for a while. Some insist Western Union invented the phrase in the 1960s; others point to a 1994 AT&T ad for the PersonaLink Services; and still others argue it was Amazon in 2006 or Google a few years later. And Gartner had Cloud Computing at the top of their Hype Cycle in 2009.

No matter the birth year, Cloud Computing has become an integral part of an organization’s infrastructure and is not going away anytime soon. A 2017 SolarWinds IT Trends report says 95% of businesses have migrated critical applications to the cloud and F5's SOAD report notes that 20% of organizations will have over half their applications in the cloud this year. It is so critical that we’ve decided to dedicate the entire month of June to the Cloud.

We’ve planned a cool cloud encounter for you this month. We’re lucky to have many of F5’s Cloud experts offering their 'how-to' expertise with multiple 4-part series. The idea is to take you through a typical F5 deployment for various cloud vendors throughout the month. Mondays, we got Suzanne Selhorn & Thomas Stanley covering AWS; Wednesdays, Greg Coward will show how to deploy in Azure; Thursdays, Marty Scholes walks us through Google Cloud deployments including Kubernetes.

But wait, there’s more!

On Tuesdays, Hitesh Patel is doing a series on the F5 Cloud/Automation Architectures and how F5 plays in the Service Model, Deployment Model and Operational Model - no matter the cloud and on F5 Friday #Flashback starting tomorrow, we’re excited to have Lori MacVittie revisit some 2008 #F5Friday cloud articles to see if anything has changed a decade later. Hint: It has…mostly. In addition, I’ll offer my weekly take on the tasks & highlights that week.

Below is the calendar for DevCentral's Cloud Month and we’ll be lighting up the links as they get published so bookmark this page and visit daily! Incidentally, I wrote my first Cloud tagged article on DevCentral back in 2009. And if you missed it, Cloud Computing won the 2017 Preakness. Cloudy Skies Ahead!

June 2017

 

Monday

Tuesday

Wednesday

Thursday

Friday

 

28

29

30

31

1

Cloud Month Intro & Calendar

2

Flashback Friday: The Many Faces of Cloud

Lori MacVittie

3

4

5

Successfully Deploy Your Application in the AWS Public Cloud

Suzanne Selhorn

6

Cloud/Automated Systems need an Architecture

Hitesh Patel

7

The Hitchhiker’s Guide to BIG-IP in Azure

Greg Coward

8

Deploy an App into Kubernetes in less than 24 Minutes

Marty Scholes

9

F5 Flashback Friday: The Death of SOA Has (Still) Been Greatly Exaggerated

-Lori

10

11

12

Secure Your New AWS Application with an F5 Web Application Firewall

-Suzanne

13

The Service Model for Cloud/Automated Systems Architecture

-Hitesh

14

The Hitchhiker’s Guide to BIG-IP in Azure – ‘Deployment Scenarios

-Greg

15

Deploy an App into Kubernetes Even Faster (Than Last Week)

-Marty

16

F5 Flashback Friday: Cloud and Technical Data Integration Challenges Waning

-Lori

17

18

19

Shed the Responsibility of WAF Management with F5 Cloud Interconnect

-Suzanne

20

The Deployment Model for Cloud/Automated Systems Architecture

-Hitesh

21

The Hitchhiker’s Guide to BIG-IP in Azure – ‘High Availability’

-Greg

22

Deploy an App into Kubernetes Using Advanced Application Services

-Marty

23

Flashback Friday: Is Vertical Scalability Still Your Problem?

-Lori

24

25

26

​Get Back Speed and Agility of App Development in the Cloud with F5 Application Connector

-Suzanne

27

The Operational Model for Cloud/Automated Systems Architecture

-Hitesh

28

The Hitchhiker’s Guide to BIG-IP in Azure – ‘Life Cycle Management’

-Greg

29

Peek under the Covers of your Kubernetes Apps

-Marty

30

Cloud Month Wrap!

 

Titles subject to change...but not by much.

ps

 




Device Discovery on BIG-IQ 5.1

Posted in f5, big-ip, cloud computing, adc, application delivery, devcentral, aws, azure, access, big-iq by psilva on May 23rd, 2017

The first step in using a BIG-IQ to manage BIG-IP devices

BIG-IQ enables administrators to centrally manage BIG-IP infrastructure across the IT landscape.  BIG-IQ discovers, tracks, manages, and monitors physical and virtual BIG-IP devices - in the cloud, on premise, or co-located at your preferred datacenter.

Let’s look at how to get BIG-IQ 5.1 to gather the information needed to start managing a BIG-IP device. This gathering process is called Device Discovery.

To get started, the first thing is to logon to the BIG-IQ

iq2.jpg

Once in, the first thing you do is let the BIG-IQ know about the BIG-IP device that you want to manage. Here, in Device Management>Inventory>BIG-IP Devices, we’ll click Add Device.

iq3.jpg

Here we’ll need the IP address, user name and password of the device you want to manage. If the device you want to manage is part of a BIG-IP Device Service Cluster (DSC), you’ll probably want to manage that part of its configuration by adding it to a DSC group on the BIG-IQ. After selecting a DSC, tell the BIG-IQ how to handle synchronization when you deploy configuration changes so that when you deploy changes to one device, the other DSC members get the same changes. Best practice is to let BIG-IQ do the sync.

iq5.jpg

Next click Add at the bottom of the page to start the discovery process.

iq6.jpg

Once the device recognizes your credentials, it’ll prompt you to choose the services that you want to manage. You always select LTM, even if you only mange other services because the other services depend on LTM. To finish the device discovery task, click Discover.

iq7.jpg

The BIG-IQ gathers the information it needs for each of the services you requested. This first step takes only a few moments while the BIG-IQ discovers your devices. You are done with discovery once the status update reads, Complete import tasks.

iq8.jpg

Now, we need to import the service configurations that the BIG-IQ needs before we can start managing that BIG-IP device. Click the link that says, Complete import tasks.

Next, you’ll begin the process of importing the BIG-IP LTM services for this device. Just like the discovery task, you’ll import LTM first.

Click Import.

iq9.jpg

This could take a little time depending on how many LTM objects are defined on this BIG-IP device. When the import finishes, BIG-IQ will display the date and time of when the operation was completed.

iq91.jpg

Now, we repeat the process for the second service provisioned on this device.

iq92.jpg

Importing an access device like BIG-IP APM is slightly different. Part of the import task is to identify the Access Group that this device uses to share its configuration. Whether you’re adding to an existing or creating a new access group, when you’re done entering the name of the group, click Add to start the import process. Here again, the time to process depends on how many BIG-IP APM configuration objects are defined on the device.

iq93.jpg

When the BIG-IP APM services import finishes and the time completed displays, you can simply click Close to complete the task.

iq94.jpg

You can now see that the device has been added to BIG-IQ.

iq95.jpg

That’s it! Now you can start managing the BIG-IP LTM and APM object on this device. For this article, we only imported LTM and APM objects but the process is the same for all services you manage.

Thanks to our TechPubs group and watch the video demo here.

ps

Related:

What is BIG-IQ




Updating an Auto-Scaled BIG-IP VE WAF in AWS

Posted in security, f5, big-ip, cloud computing, infrastructure, waf, aws by psilva on May 23rd, 2017

Update servers while continuing to process application traffic.

Recently we've been showing how to deploy BIG-IP (and F5 WAF) in various clouds like Azure and AWS.

Today, we’ll take a look at how to update an AWS auto-scaled BIG-IP VEBIG-IP VE web application firewall (WAF) that was initially created by using this F5 github template. This solution implements auto-scaling of BIG-IP Virtual Edition (VE) Web Application Firewall (WAF) systems in Amazon Web Services. The BIG-IP VEs have the Local Traffic Manager (LTM) and Application Security Manager (ASM) modules enabled to provide advanced traffic management and web application security functionality. As traffic increases or decreases, the number of BIG-IP VE WAF instances automatically increases or decreases accordingly.

Prerequisites:

asw1.jpg

So, let’s assume you used the CFT to create a BIG-IP WAF in front of your application servers…and your business is so successful that you need to be able to process more traffic. You do not need to tear down your deployment and start over – you can make changes to your current deployment while the WAF is still running and protecting your environment.

For this article, a few examples of things you can change include increasing the throughput limit. For instance, When you first configured the WAF, you choose a specific throughput limit for BIG-IP. You can update that. You may also have selected a smaller AWS instance size and now want to choose a larger AWS instance type and add more CPU. Or, you may have set up your auto-scaling group to launch a maximum of two instances and now you want to be able to update the auto-scaling group attributes and add three.

This is all possible so let’s check it out.

The first thing we want to do is connect to one of the BIG-IP VE instances and save the latest configuration. We open putty, login and run the TMSH command (save /sys ucs /var/tmp/original.ucs) to save the UCS config file.

asw2.jpg

Then we use WinSCP to copy the UCS files to the desktop. You can use whatever application you like and copy the file wherever you like as this is just a temporary location.

asw3.jpg

Once that’s done, open the AWS Management Console and go to the S3 bucket. This bucket was created when you first deployed the CFT and locate yours.

asw456.jpg

When you find your file, click it and then click the Backup folder.

asw7.jpg

Once there, now upload the UCS file into that folder.

asw89.jpg

The USC is now in the folder.

asw91.jpg

The last step is to redeploy the CFT and change the selected options. From the main AWS Management Console, click CloudFormation, select your Stack and under Actions, click Update Stack.

asw9293.jpg

Next, you can see the template we originally deployed and to update, click Next.

asw94.jpg

Scroll down the page to Instance Configuration to change the instance type size.

asw95.jpg

Right under that is Maximum Throughput to update the throughput limit.

asw96.jpg

And a little further down under Auto Scaling Configuration is where you can update the max number of instances. When done click Next at the bottom of the page.

asw97.jpg

It’ll ask you to review and confirm the changes. Click Update.

asw9899.jpg

You can watch the progress and if your current BIG-IP VE instance is actively processing traffic, it will remain active until the new instance is ready.  Give it a little time to ensure the new instance is up and added to the auto scaling group before we terminate the other instance.

asw991.jpg

When it is done, we’ll confirm a few things.

Go to the EC2 Dashboard and check the running instances. We can see the old instance is terminated and the new instance is now available. You can also check the instance size and within the auto scaling group you can see the new maximum for number of instances.

asw99234.jpg

And we’re deployed.

You can follow this same workflow to update other attributes of your F5 WAF. This allows you to update your servers while continuing to process traffic.

Thanks to our TechPubs group, you can also watch the video demo.

ps

Related:

 




Deploy BIG-IP VE in AWS

Posted in Uncategorized, f5, big-ip, cloud, cloud computing, devcentral, aws, access by psilva on January 23rd, 2017

aws_logo.jpgCloud is all the rage these days as it has matured into a bona fide, viable option to deploy your applications. While attractive, you may also want to apply, mimic or sync your traditional data center policies like high availability, scalability and predictability in the cloud.

 




Lightboard Lessons: BIG-IP in Hybrid Environments

Posted in security, f5, big-ip, ssl vpn, cloud, silva, application delivery, lightboard, devcentral, remote access, saml, aws, azure, saas by psilva on October 12th, 2016

A hybrid infrastructure allows organizations to distribute their applications when it makes sense and provide global fault tolerance to the system overall. Depending on how an organization’s disaster recovery infrastructure is designed, this can be an active site, a hot-standby, some leased hosting space, a cloud provider or some other contained compute location. As soon as that server, application, or even location starts to have trouble, organizations can seamlessly maneuver around the issue and continue to deliver their applications.

Driven by applications and workloads, a hybrid environment is a technology strategy to integrate the mix of on premise and off-premise data compute resources. In this Lightboard Lesson, I explain how BIG-IP can help facilitate hybrid infrastructures.

ps

Related:

 

Watch Now:



AWS re:Invent 2015 – The F5 Ready Program (feat Pickering)

Posted in f5, big-ip, cloud computing, silva, video, application delivery, infrastructure, aws by psilva on October 8th, 2015

Brian Pickering, Regional VP - Cloud Partners, talks about F5 Ready, a program that makes sure that F5 BIG-IP virtual editions are compatible with a growing list of cloud providers via an F5-driven verification process and flexible licensing and usage models. Gain cloud confidence by extending proven F5 solutions to a broad set of F5 Ready cloud environments with a hybrid delivery model and consistent policies. Take your BIG-IP VE license and run it in the cloud!

ps

Related:

Watch Now:



AWS re:Invent 2015 – Programmability in the Cloud (feat Applebaum)

Posted in f5, cloud, silva, video, aws by psilva on October 8th, 2015

Programmability and orchestration are critically important with cloud deployments and Alex Applebaum, Sr. Product Management Engineer, explains why and talks about ways organizations can use BIG-IP programmability in the cloud. Yet another critical F5 service, always available on the BIG-IP platform, now enabled for the cloud.

ps

Related:

Connect with Peter: Connect with F5:
o_linkedin[1] o_rss[1] o_twitter[1]   o_facebook[1] o_twitter[1] o_slideshare[1] o_youtube[1]
Watch Now:



AWS re:Invent 2015 – Web Application Firewall in the Cloud (feat Haynes)

Posted in security, f5, application security, cloud computing, silva, video, aws, policy by psilva on October 7th, 2015

WAFs are one an organization’s key line of defenses against web application attacks and Robert Haynes, Marketing Services Architect, shares some of the app security considerations organizations must face when deploying their critical applications in the cloud. WAFs have typically been deployed on-premises within a traditional data center but those same protections and policies must follow the application to the cloud. Robert give us the scoop on how that can be accomplished.

ps

Related:

Connect with Peter: Connect with F5:
o_linkedin[1] o_rss[1] o_twitter[1]   o_facebook[1] o_twitter[1] o_slideshare[1] o_youtube[1]
Watch Now:




« Older episodes ·