Best way to learn Ansible and the whole idea of automation is to start from the small playbooks and then grow big. If you first automate simple tasks, even those that may be easier and quicker to perform from the command line, you will learn how Ansible is working. Let’s say, we want to test if SNMP is responding on the remote host (we name it HostA). We will use SNMPv3 and authPriv security model. And of course, we want to write the Ansible playbook and run it on server HostNOC.
It is time for some new final tuning of my small certificate signing service. In previous parts, I showed you what AWS Lambda service is and how to import simple Python application into serverless microservice. I also connected Lambda function to S3 storage service where I put certificates and key files. Then I added a trigger to the function, so Lambda function will execute automatically every time someone uploads new CSR file with certificate request to S3 bucket. Now I will show you not only how to make this function serverless but also storageless using API Gateway. It is not standard approach but in some scenarios might be interesting. So we will connect API Gateway and Lambda without S3 backend for keys and certificates.
This is third part of the tutorial of AWS Lambda. In previous chapters I presented my small Python app I created for signing certificate requests and imported it to AWS Lambda service (check AWS Lambda guide part I – Import your Python application to Lambda). Then I modified the code so instead of using reference to static local files we can read and write to S3 bucket (check AWS Lambda guide part II – Access to S3 service from Lambda function). Now let’s move forward and add S3 trigger in Lambda function.
We can always execute Lambda function manually either from web panel or using CLI. We can also execute it from our other application if required. But microservices are often triggered by events. In this article I will show you how to automatically sign certificate using my Lambda function when request file is uploaded to S3 bucket. Let me show you how to program S3 trigger in Lambda.
In previous chapter I talked a little what is AWS Lambda and idea behind serverless computing. Furthermore I presented small Python application I wrote to sign certificate requests using my CA authority certificate (how to create such you can find in my post How to act as your own local CA and sign certificate request from ASA). Then after importing the sandboxed Python environment (required because of non-standard library used for SSL, whole procedure is described in my post How to create Python sandbox archive for AWS Lambda) and small change in the code we managed to execute it in Lambda. Also I mentioned that we can use other AWS services in our code, in example Access to S3 service from Lambda.
As you remember the initial version of my application have static paths to all files and assume that it can open it from folders on local hard drive. If you run function in Lambda you need a place where you can store files. This place is AWS S3. In this chapter I show you how to use S3 service in function on Lambda. We will use boto3 library that you can locally install on your computer using pip.
AWS Lambda contain now 1067 Python libraries that we can use in our programs. The number is big and small at the same time. It should give us flexibility in writing apps but same time is limitation – there are many non-standard libraries that are better replacement for default ones. I will show you how to create Python application sandbox and then ZIP archive for AWS Lambda that will contain libraries not available by default so you can use them in your serverless application.
Serverless applications idea is that we don’t have access to operating system. We just run our code in own sandbox. Therefor we can’t just install new package if we miss it. Solution is providing ZIP archive with code of our application and python environment that have all non-standard libraries inside. Let me show you how to do this.
Why Swift? Because I got bored one evening 🙂 Well, that’s partially true. I’ve heard good opinions about Swift language from professional developers. It’s now open language available for many platforms, not only Apple products. I also like to try new things and was curious if learning at least basics of new language by myself would be hard and how quick I can do that. Also Apple was very helpful because of nice tutorial from Apple Developers which show step by step how to use XCode, build application interface and connect code to objects. There are many examples on Internet, I think the hardest thing at the beginning was to understand some language semantic constructions and get familiar with API of system libraries. Also, if you ever start programming in Swift remember that current version is Swift 3.0, but many examples on the web are from older versions and won’t work without minor or major changes to the code.
So what was my concept of an application? Easy, I just wanted to get information about firmware version installed on ASA. But of course if you have idea of other apps then sky is the limit 😉
Apple care about users privacy and security quite well. Of course it’s a matter of opinion but Apple put strong focus on encryption and peer authentication. In 2015 Apple introduced App Transport Security (ATS) as part of their Network Framework With every release they are putting more and more responsibility on developers and content operators to provide proper traffic encryption proper certificate signing and chain etc. That means if application is trying to connect to HTTP server that does not support latest TLSv1.2 connection should fail.
There is no doubt that ATS is good for end users and that’s right direction every corporation should follow. But switching to TLSv1.2 is not something that can be done just like that, obtaining signed certificate expensive option, especially for development environments or if you are writing apps to just test something or for fun. Self-signed certificates are the solution for such cases but there are few problems that we can encounter.
I was not planning this chapter and putting away Perl for even a moment, but I have some talk with my VeriFone colleague on scripting, REST API and how creating web server which uses REST API back end to control certain parameters of firewall is not that easy and straightforward. We both have some programming and scripting experience but neither of us is a programmer. We both know more or less several programming languages but we are not proficient. But we both have (at least we thing we have) good fundamental knowledge about programming.
The topic circulated around web page that will let display and manipulate ACL entries on firewall in non-SDN data center. Feature quite simple that most independent firewall management platforms can do. The problem is that most of those applications are using CLI via SSH to send commands and parse output, that’s exactly how Cisco ASDM is working in example, but we wanted something maybe a little more flexible, reliable… We both agreed that JSON is flexible structure that should be easy to use. So how to write a comprehensive script?
First published: 09/Jan/2017
Last update: 09/Jan/2017
In chapter Cisco ASA REST API – Part I: Getting started primary configuration for REST API has been done on firewalls then in chapter Cisco ASA REST API – Part III: Checking if prefix is directly connected first script in Perl has been created. Let’s now look at ways we can troubleshoot REST API calls and status on Cisco ASA. This may be crucial to detect cause of the problem. Troubleshooting requires command line access to firewall in enabled mode.
In this chapter I will use script I presented previously and also will execute some REST API methods using Firefox RESTClient extension mentioned if first chapter. Because output of debug can be extensive listings will contain only crucial parts.
Debugging REST API means checking particular component for errors or other logs that might be interested for us. Command execution require in first place declaration which component will be debugged.
asav-1# debug rest-api ? agent Rest-API Agent cli Rest-API cli handling client Rest-API client request handling daemon Rest-API debug/syslog handling process Starting/Stopping of Rest-API Agent token-auth Rest-API Token authentication
First published: 03/Jan/2017
Last update: 03/Jan/2017
It’s time to do some programming and really use REST API for something good. The first script will be used to check if specified prefix is directly connected to any of firewall interfaces. Script requires two arguiments: checked IP address and IP address of firewall. The execution of script will be as below
$ ./IfDirectlyConnected.pl Usage: IfDirectlyConnected.pl [Checked IP Address] [Firewall Management IP]
At this demo script require IP addresses to be used and is not checking if arguments are IP addresses, just simply validating if two it’s executed with two arguments.
Please take a moment to look back to my post Cisco ASA REST API – Lab topology and programming language where I explained the topology of simulated network and presented IP addresses assigned to each device. Routing is configured and all subnets are reachable.
We will test te script on
asav-1 firewall. The expected results are as follow:
$ ./IfDirectlyConnected.pl 10.0.12.5 172.16.1.51 Checking address 10.0.12.5 on firewall 172.16.1.51 RESULT: Destination route is directly connected $ ./IfDirectlyConnected.pl 10.0.24.5 172.16.1.51 Checking address 10.0.24.5 on firewall 172.16.1.51 RESULT: Route in routing table but not directly connected $ ./IfDirectlyConnected.pl 10.0.99.5 172.16.1.51 Checking address 10.0.99.5 on firewall 172.16.1.51 RESULT: Subnet not in routing table
Script is available on my GitHub