Author Archives: packetmischief.ca
Author Archives: packetmischief.ca
In a throwback to the problems I dealt with using AirPlay across VLANs, I recently jumped through similar hoops for Sonos speakers. There are many forum and blog posts out there that describe (or attempt to describe) how to make this work, however all of the ones I read suffered from one or both of these problems:
This post will dive deep on what's happening on the wire when a Sonos controller (eg, your mobile phone running the Sonos app) tries to talk with the players (the speakers) on the network. The focus will be how to make this process work when those two devices are in different VLANs.
What you read below works successfully with Sonos Beam, Sonos Sub, and Sonos Move using the Sonos S1 app.
The AWS Cloud Development Kit (CDK) is an "open source software development framework to define your cloud application resources using familiar programming languages". When CDK launched in 2019, I remember reading the announcement and thinking, "Ok, AWS wants their own Terraform-esque tool. No surprise given how popular Terraform is." Months later, my friend and colleague Matt M. was telling me how he was using CDK in a project he was working on and how crazy cool it was.
I finally decided to give CDK a go for one of my projects. Here is what I discovered.
This article was originally posted on the Amazon Web Services Security Blog.
AWS CloudFormation is a service that lets you create a collection of related Amazon Web Services and third-party resources and provision them in an orderly and predictable fashion. A typical access control pattern is to delegate permissions for users to interact with CloudFormation and remove or limit their permissions to provision resources directly. You can grant the AWS CloudFormation service permission to create resources by creating a role that the user passes to CloudFormation when a stack or stack set is created. This can be used to ensure that only pre-authorized services and resources are provisioned in your AWS account. In this post, I show you how to conform to the principle of least privilege while still allowing users to use CloudFormation to create the resources they need.
I have a cron job that renews an SSL
certificate from Let's
Encrypt, and then restarts the
smtpd daemon so that the new certificate is
picked up. This all works fine--as proven by both the presence of a new, valid
cert on disk, and smtpd successfully restarting--but cron never sends an email
with the output of the job. What gives?
This is a running list of unusual data found in the Domain Name System.
Typically, DNS stores name-to-IP (for example,
foo.example.net -> 192.0.2.123) and IP-to-name mappings (i.e., the inverse). But, the
DNS is arguably the biggest, most distributed key/value store on the planet,
making it a great place to stash all kinds of simple data.
For years now I've had a light switch that can be programmed to turn itself on/off on a schedule. The switch is programmed with the date, time, time zone, and lat/long and then you can create a schedule such as, "turn the lights on at sun set". It works pretty well except when 1/ daylight savings time starts or stops (the schedule doesn't adjust itself) or 2/ the power goes out (bye, bye all programming).
This slight annoyance coupled with my desire for a project I could geek out on lead me to look into software-controllable light switches.
AWS Serverless Application Model (SAM) is a framework for building serverless applications on AWS. One of the components of SAM is a template specification. SAM templates would look and feel familiar to anyone who has used AWS CloudFormation to define their infrastructure as code, however they are not completely interchangeable. There are multiple reasons why you might want to convert from SAM to native CloudFormation:
AWS::Serverlesstransform in its templates and transforms are not supported by stack sets.
This post will show you how to take an existing SAM application and convert it to a CloudFormation template (CFT). As a CFT, the challenges listed above can be avoided.
This article was originally posted on the Amazon Web Services Architecture blog.
In a recent customer engagement, Quantiphi, Inc., a member of the Amazon Web Services Partner Network, built a solution capable of pre-processing tens of millions of PDF documents before sending them for inference by a machine learning (ML) model. While the customer's use case--and hence the ML model--was very specific to their needs, the pipeline that does the pre-processing of documents is reusable for a wide array of document processing workloads. This post will walk you through the pre-processing pipeline architecture.
I recently used AWS DataSync as part of a lab I was building. These are my notes for using DataSync to replicate an Amazon Elastic File System (EFS) share from one region to another.
AWS DataSync is a managed service that enables replication of data between AWS services and from on-prem to AWS. It automates the scheduling of transfer activities, validates copied data, and uses a purpose-built network protocol and multi-threaded architecture to achieve very high efficiency on the wire.
The use case I needed to tackle was replicating an Amazon EFS share in one region to an EFS share in a different region (a one-way replication). (DataSync can also connect to Amazon S3 and Amazon FSx for Windows File Server)
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.
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:
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.
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?
Often in my career I have to make an estimate about the so-called “level of effort” (LoE) to do a thing.
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
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!
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.
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.
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.