Archive

Category Archives for "packetmischief.ca"

Multicast Routing in AWS

Consider for a moment that you have an application running on a server that needs to push some data out to multiple consumers and that every consumer needs the same copy of the data at the same time. The canonical example is live video. Live audio and stock market data are also common examples. At the re:Invent conference in 2019, AWS announced support for multicast routing in AWS Virtual Private Cloud (VPC). This blog post will provide a walkthrough of configuring and verifying multicast routing in a VPC.

AWS ABCs: Granting A Third-Party Access to Your Account

There can be times when you’re working on the AWS Cloud where you need to grant limited access to your account to a third-party. For example:

  • A contractor or a specialist needs to perform some work on your behalf
  • You’re having AWS Professional Services or a partner from the Amazon Partner Network do some work in your account
  • You’re conducting a pilot with AWS and you want your friendly neighborhood Solutions Architect to review something

In each of these cases you likely want to grant the permissions the third-party needs but no more. In other words, no granting of AdministratorAccess policies because it’s easy and just works. Instead, adherence to the principle of least privilege.

This post will describe two methods–IAM users and IAM roles–for proving limited access to third-parties.

Comparing the Two Approaches

The big difference with the IAM user approach vs the role-based approach is the way the credentials for each entity are handed out.

IAM users have long-term credentials that only change by a manual action (either the user or an administrator changes the credentials). Those credentials will continue to provide access to the account until they’re either changed or the user is disabled/deleted.

By contrast, roles Continue reading

AWS ABCs: Granting A Third-Party Access to Your Account

There can be times when you're working on the AWS Cloud where you need to grant limited access to your account to a third-party. For example:

  • A contractor or a specialist needs to perform some work on your behalf
  • You're having AWS Professional Services or a partner from the Amazon Partner Network do some work in your account
  • You're conducting a pilot with AWS and you want your friendly neighborhood Solutions Architect to review something

In each of these cases you likely want to grant the permissions the third-party needs but no more. In other words, no granting of AdministratorAccess policies because it's easy and just works. Instead, adherence to the principle of least privilege.

This post will describe two methods—IAM users and IAM roles—for proving limited access to third-parties.

3 Tools for Getting VMs From Your Datacenter to the AWS Cloud

Here’s a simple scenario: you have some Virtual Machines (VMs) in your on-premises environment, likely in VMware vSphere or Microsoft Hyper-V. You want to either fully migrate some or all of those VMs to the AWS Cloud or you want to copy a gold image to the AWS Cloud so you can launch compute instances from that image. Simple enough.

Now, how do you do it?

Can you just export an OVA of the VM, copy it up, and then boot it? Can you somehow import the VMDK files that hold the VM’s virtual drive contents? Regardless the eventual method, how do you do it at scale for dozens or hundreds of VMs? And lastly, how do you orchestrate the process so that VMs belonging to an application stack are brought over together, as a unit?

This post will answer these questions and more by providing an introduction to the services available on the AWS Cloud to discover, plan, migrate, and track VMs from on-prem to AWS.

This post assumes good working knowledge of technologies such as VMware vCenter and only basic knowledge of AWS.

Let’s just clarify some things first…

Remembering that this post is tailored for those that Continue reading

3 Tools for Getting VMs From Your Datacenter to the AWS Cloud

Here's a simple scenario: you have some Virtual Machines (VMs) in your on-premises environment, likely in VMware vSphere or Microsoft Hyper-V. You want to either fully migrate some or all of those VMs to the AWS Cloud or you want to copy a gold image to the AWS Cloud so you can launch compute instances from that image. Simple enough.

Now, how do you do it?

Can you just export an OVA of the VM, copy it up, and then boot it? Can you somehow import the VMDK files that hold the VM's virtual drive contents? Regardless the eventual method, how do you do it at scale for dozens or hundreds of VMs? And lastly, how do you orchestrate the process so that VMs belonging to an application stack are brought over together, as a unit?

9 Things to Consider When Estimating Time

Often in my career I have to make an estimate about the so-called “level of effort” (LoE) to do a thing.

  • What’s the LoE for me to do a demo for this customer?
  • What’s the LoE for me to help respond to this RFP?
  • What’s the LoE for me to participate in this conference?

The critical metric by which I usually have to measure the LoE is time. People, equipment, venue, materials, and location are rarely ever a limiting factor. Time is always the limiting factor because no matter the circumstance, you can’t just go and get more of it. The other factors are often elastic and can be obtained.

And oh how I suck at estimating time.

As soon as the question comes up, “What’s the LoE for…”, I immediately start to think, ok, if I am doing the work, I can do this piece and that piece, I can read up on this thing and get it done with slightly more time invested, and then yada, yada, yada… it’s done!

What I don’t account for is the human element. The unexpected. The fact that we’re all different and team members will go about their work in their Continue reading

9 Things to Consider When Estimating Time

Often in my career I have to make an estimate about the so-called “level of effort” (LoE) to do a thing.

  • What's the LoE for me to do a demo for this customer?
  • What's the LoE for me to help respond to this RFP?
  • What's the LoE for me to participate in this conference?

The critical metric by which I usually have to measure the LoE is time. People, equipment, venue, materials, and location are rarely ever a limiting factor. Time is always the limiting factor because no matter the circumstance, you can't just go and get more of it. The other factors are often elastic and can be obtained.

And oh how I suck at estimating time.

As soon as the question comes up, “What's the LoE for…", I immediately start to think, ok, if I am doing the work, I can do this piece and that piece, I can read up on this thing and get it done with slightly more time invested, and then yada, yada, yada… it's done!

What I don't account for is the human element. The unexpected. The fact that we're all different and team members will go about their work in their Continue reading

Five Functional Facts About AWS Service Control Policies

Following on the heels of my previous post, Five Functional Facts about AWS Identity and Access Management, I wanted to dive into a separate, yet related way of enforcing access policies in AWS: Service Control Policies (SCPs).

SCPs and IAM policies look very similar–both being JSON documents with the same sort of syntax–and it would be easy to mistake one for the other. However, they are used in different contexts and for different purposes. In this post, I’ll explain the context where SCPs are used and why they are used (and even why you’d use SCPs and IAM policies together).

Read on, dear reader!

1 – SCPs scope the permissions an AWS account has

To properly describe SCPs, I need to introduce a new service: AWS Organizations. Organizations is a service that is used to bring multiple AWS accounts together under a common management structure. For example, if you wanted to enforce the use of encryption on S3 buckets across all the AWS accounts used within your company, you could do that via AWS Organizations. Additional benefits of Organizations include consolidated billing, integration with certain services such as AWS CloudTrail, and streamlined sharing of resources between accounts using Continue reading

Five Functional Facts About AWS Service Control Policies

Following on the heels of my previous post, Five Functional Facts about AWS Identity and Access Management, I wanted to dive into a separate, yet related way of enforcing access policies in AWS: Service Control Policies (SCPs).

SCPs and IAM policies look very similar—both being JSON documents with the same sort of syntax—and it would be easy to mistake one for the other. However, they are used in different contexts and for different purposes. In this post, I'll explain the context where SCPs are used and why they are used (and even why you'd use SCPs and IAM policies together).

Read on, dear reader!

Amazon CloudFront with WordPress as Infrastructure as Code

There are roughly a GAJILLION articles, blogs, and documents out there that explain how to setup Amazon CloudFront to work with WordPress.

Most of them are wrong in one or more ways.

  • They advise a type of cache behavior that is incorrect for one or more WordPress assets.
  • They fail to provide any advice for WordPress assets that need specific cache behavior.
  • The article/blog/document is stale and hasn’t been updated to reflect changes in newer versions of WordPress.

Rather than fall into the trap of writing yet another article for whatever the “now current” version of WordPress is that will likely fall victim to one or more of the conditions listed above, I’m going to take a different approach.

I’m going to codify the CloudFront configuration, version it on GitHub, and adopt an “infrastructure-as-code” (IaC) mentality. This blog post will describe the overall architecture and provide some context, but the actual mechanics of setting up CloudFront to work with WordPress will live (and evolve!) in the IaC files themselves which will be under version control.

Let’s do it!

The Architecture

I’ll say this up front: this architecture may not be for everyone (but I have a sneaky Continue reading

Five Functional Facts about AWS Identity and Access Management

This post is part of an open-ended series I’m writing where I take a specific protocol, app, or whatever-I-feel-like and focus on five functional aspects of that thing in order to expose some of how that thing really works.

The topic in this post is the AWS Identity and Access Management (IAM) service. The IAM service holds a unique position within AWS: it doesn’t get the attention that the machine learning or AI services get, and doesn’t come to mind when buzzwords like “serverless” or “containers” are brought up, yet it’s used by–or should be used by–every single AWS customer (and if you’re not using it, you’re not following best practice, tsk, tsk) so it’s worthwhile to take the time to really get to know this service.

Let’s begin!

1 – The root user supersedes IAM policies

The main reason I threw a bit of shade about following best practice and always using IAM has to do with the root user in an account. The root user is what’s created when a new AWS account is opened. The username for the root user is always an email address and the root user is able to log into the AWS account Continue reading

Five Functional Facts about AWS Identity and Access Management

This post is part of an open-ended series I'm writing where I take a specific protocol, app, or whatever-I-feel-like and focus on five functional aspects of that thing in order to expose some of how that thing really works.

The topic in this post is the AWS Identity and Access Management (IAM) service. The IAM service holds a unique position within AWS: it doesn't get the attention that the machine learning or AI services get, and doesn't come to mind when buzzwords like “serverless” or “containers” are brought up, yet it's used by-or should be used by-every single AWS customer (and if you're not using it, you're not following best practice, tsk, tsk) so it's worthwhile to take the time to really get to know this service.

Let's begin!

Can IT Certifications Become a Liability?

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?

I earned my first certification in 2001, the next in 2002, and just kept going from there. My background and work focus since 2001 has been networking so that’s where I’ve focused my certification efforts. I’ve been fortunate enough to have multiple employers who supported my certification journey. This certainly made the journey easier by taking care of (at least some of) the financial burden and providing an environment that supported taking time to study.

Of the certifications I obtained, some required taking just a single multiple choice exam. Others required passing up to four individual exams (within a certain time window) to achieve certification. One certification in particular required passing a multiple choice exam in order to qualify for an 8-hour hands-on lab exam (which I had to take twice).

Prep time for these exams has varied from a few weeks of reading/note taking to close to two years of intense reading, notes, flashcards, and lab work.

All but 2 certifications I hold (or have held) require regularly Continue reading

AWS ABCs – Network Building Blocks

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.

The basis for building the model will be a single VM on-prem and a single compute instance in AWS. I’m going to build all the networking constructs around both of these elements, starting from the outer-most layers and working closer and closer to the VM/instance.

Our VM and compute instance need them some networking!

A Note on Layer 2

On the AWS platform there is no explicit building blocks for Layer 2 connectivity. There’s no “elastic virtual Continue reading

AWS ABCs — Network Building Blocks

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.

AWS ABCs – Can I Firewall My Compute Instances?

In a previous post, I reviewed what a public subnet and Internet Gateway (IGW) are and that they allowed outbound and inbound 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.

Security Groups

In a nutshell: security groups (SGs) define what traffic is allowed to reach an instance.

“Security group” is a bit of a weird name for what is essentially a firewall that sits in front of an instance, however if you think about it in terms of all servers at a particular tier in an N-tier application (eg, all the web servers) or all the servers that have a common function (eg, all PostgreSQL servers) and how each group would have its own security requirements when it comes to allowed ports, protocols, and IP addresses, then it makes a bit more sense: the security rules appropriate for a group of servers are all put together within Continue reading

AWS ABCs — Can I Firewall My Compute Instances?

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.

AWS ABCs – EC2 Internet Connectivity

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.

TL;DR

  • Internet Gateway == static NAT: 1-to–1 mapping between the private IP address assigned to an instance and a public IP address that gets assigned to the instance. Note this implies that NAT works in both directions (in- and outbound) and enables direct reachability to the instance from the Internet via its public IP address.
  • NAT Gateway == NAT overload, aka port address translation: all instances behind the NAT Gateway are mapped to a single public IP address.
  • No gateways == no NAT! No Internet Continue reading