I've been asking myself an uncomfortable question lately: "Can IT certifications become a liability? Have I reached a point where my IT certifications have become a liability to me?"
Given that my technical background is largely in the networking space (exhibit A, exhibit B, exhibit C (CIE)), one of the first things I tried to wrap my head around when being introduced to AWS is how networking works in the AWS cloud.
What I attempted to do was build a mental model by relating cloud networking constructs such as Virtual Private Cloud (VPC), subnets, and routing tables to on-prem, physical networking constructs. This worked pretty well but I did get tripped up at times because some of these constructs don't map exactly one-for-one.
This post will explain the mental model I used while also calling attention to the elements or behaviors that don't map exactly between on-prem and AWS.
In a previous post, I reviewed what a public subnet and Internet Gateway (IGW) are and that they allowed outbound and _in_bound connectivity to instances (ie, virtual machines) running in the AWS cloud.
If you're the least bit security conscious, your reaction might be, "No way! I can't have my instances sitting right on the Internet without any protection".
Fear not, reader. This post will explain the mechanisms that the Amazon Virtual Private Cloud (VPC) affords you to protect your instances.
So, you've created a compute instance (ie, a virtual machine) on Amazon EC2. Next question: does the instance require access to and/or from the Internet?
Protip: just because you created the instance in the public cloud, i.e. the cloud that you get to over the Internet, it doesn't mean that your instances all need to sit on the Internet. They can have direct inbound and outbound Internet access, no Internet access, or something in between (which I'll explain).
The basic building block for networking on AWS is the VPC (Virtual Private Cloud). Within a VPC, you define your IP space, gateways, ACLs, DHCP options, and more. Gateways will be the focus of this article.
Continuing on with the theme of previous cheat sheet articles, this article will help decode the format for Amazon Web Services' Elastic Compute Cloud (EC2) instance types.
Ok, you've just launched an Amazon EC2 instance (ie, a virtual machine) and you're ready to login and get to work. Just once teeeensy problem though... you have no idea how to actually connect to the instance!
This post will walk through how to log into brand new Linux/BSD and Windows instances (the steps are slightly different for different OS families).
For the past few months I've been involved in a case study project with some colleagues at Cisco where we've been researching what the most relevant software skills are that Cisco's pre-sales engineers could benefit from. We're all freaking experts at Outlook of course (that's a joke ?) but we were interested in the areas of programming, automation, orchestration, databases, analytics, and so on. The end goal of the project was to identify what those relevant skills are, have a plan to identify the current skillset in the field, do that gap analysis and then put forward recommendations on how to close the gap.
This probably sounds really boring and dry, and I don't blame you for thinking that, but I actually chose this case study topic from a list of 8 or so. My motivation was largely selfish: I wanted to see first-hand the outcome of this project because I wanted to know how best to align my own training, study, and career in the software arena. I already believed that to stay relevant as my career moves along that software skills would be essential. It was just a question of what type of skills and in which specific areas.
I spent a long time creating my first Spark bot, Zpark. The first commit was in August and the first release was posted in January. So, six months elapsed time. It's also over-engineered. I mean, all it does is post messages back and forth between a back-end system and some Spark spaces and I ended up with something so complex that I had to draw a damn block diagram in the user guide to give people a fighting chance at comprehending how it works.
Its internals could've been much simpler. But that was part of the point of creating the bot: examining the proper architecture for a scalable application, learning about new technologies for building my own API, learning about message brokers, pulling my hair out over git's eccentricities and ultimately, having enough material to write this blog post.
In this post I'm going to break down the different functional components of Zpark, discuss what each does, and why-or not-that component is necessary. If I can achieve one goal, it will be to retire to a tropical island ASAP. If I can achieve a second goal, it will be to give aspiring bot creaters (like yourself, presumably) a strong mental model of a Spark bot to aid their development.
Cisco Encrypted Traffic Analytics (ETA) sounds just a little bit like magic the first time you hear about it. Cisco is basically proposing that when you turn on ETA, your network can (magically!) detect malicious traffic (ie, malware, trojans, ransomware, etc) inside encrypted flows. Further, Cisco proposes that ETA can differentiate legitimate encrypted traffic from malicious encrypted traffic.
The immediate mental model that springs to mind is that of a web proxy that intercepts HTTP traffic. In order to intercept TLS-encrypted HTTPS traffic, there's a complicated dance that has to happen around building a Certificate Authority, distributing the CA's public certificate to every device that will connect through the proxy and then actually configuring the endpoints and/or network to push the HTTPS traffic to the proxy. This is often referred to as "man-in-the-middle" (MiTM) because the proxy actually breaks into the encrypted session between the client and the server. In the end, the proxy has access to the clear-text communication.
Is ETA using a similar method and breaking into the encrypted session?
In this article, I'm going to use an analogy to describe how ETA does what it does. Afterwards, you should feel more comfortable about how ETA works and not be worried about any magic taking place in your network. ?