At Fairwinds we take an opinionated approach on how CI/CD should be done when Docker and Kubernetes are involved. In the following sections, I will outline the guiding principles of our opinions, and then lay out a typical CI/CD workflow that we use. I’ll also share some code that will enable you to give it a shot if you want. None of these principles are brand new or earth-shattering, but the combination makes for a repeatable, sustainable, and safe CI/CD pipeline that many of our customers love.

Guiding Principles

Containers Should Be Immutable

Docker allows you to rewrite a tag when you push a container. A common example of this is the latest tag. This is a dangerous practice because it presents a possible scenario where you don’t know what code is running in your container. We instead take the approach that all tags are immutable, so we tie them to an immutable, unique value that can be found in our codebase — the commit ID. This directly connects a container to the code that it was built from and erases any doubt that we know exactly what is inside that container.

Release The Container That Was Tested

In line with the first principle, the immutable container that we have deployed to a staging/dev/QA environment and then tested (hopefully) should be the same exact container that gets deployed to production. This eliminates any concern that something might change when deployed to production. We handle this by triggering a release to production using a git tag and releasing the container with the commit ID of the tag.

Keep Secrets And Config Out Of The Container

Since a container should be considered an immutable artifact of our build process, configuration should never be “baked in.” Configuration should be stored in a configmap in the Kubernetes cluster, and secrets should be stored, you guessed it, in Kubernetes secrets. This allows the deployment of the container to be configured per environment without making changes to the container itself.

Deploy With Helm

At Fairwinds, we use Helm to template all of the yaml that gets deployed to Kubernetes. This allows the easy configuration of multiple environments and their config. In addition, it makes it easier to keep track of logical groupings or “releases.”

Use A Git-Based Workflow

All CI/CD pipelines should be triggered by Git operations. This falls in line with a normal developer workflow, and makes the pipeline more accessible to developers. In addition, it works well with the previous concept of immutability being tied to a commit ID.

Build Inside Docker

We strongly discourage the use of what a former co-worker referred to as “artisanal hand-crafted build machines” that contain a random assortment of dependencies and tools. If you build inside the container, you can control all dependencies and tools in your code and never have to worry about which “builder” is running your pipeline. Docker’s multistage builds make it easy to do this while also keeping your deployed runtime image as small as possible.

Take Advantage Of Caching

Docker images can be cached and re-used. We recommend the use of this feature as much as possible in order to keep build times to a minimum. The cache images should be pushed to a repository or the caching features of your CI/CD system should be used to maximize efficiency.

Example Pipeline

I’m going to lay out step-by-step a normal pipeline that we would set up for a customer. It takes into account all of the principles in the previous section, and will provide a path from code to production “In X easy steps!”

The process goes like this:

1. Make a feature branch
2. Push that branch and open a PR — this gets built and deployed to an ephemeral namespace that you can use to test the changes. Iterate until it’s ready to go
3. Merge the feature branch to master — this triggers a build and a deployment to a staging environment
4. Once the staging environment reaches a state that is ready for production, tag a release
5. The tag gets deployed to production using the same container that was built for staging, but using production configuration

Looking at the process, we can see several “loops.” These are feedback loops that can be used to improve quality, test code, etc. The goal is to make these small and fast so that we can release code that is tested and manageable.

Go Forth And Make Pipelines

If you like the way we do CI/CD at Fairwinds, you can have your very own pipelines just like ours! We use a set of bash scripts that do all of this for us. We just have to create some config files and we get a setup very similar to the one in this article. The repo is called rok8s-scripts (pronounced “rocket scripts”), and as always, PRs are accepted.

7 Habits Of Highly Effective CI/CD Pipelines was originally published in uptime 99 on Medium, where people are continuing the conversation by highlighting and responding to this story.

So you built a cluster. Maybe you have some apps deployed. You’re sold on this whole Kubernetes thing. Now what do you do?

There are a lot of things you can do next. You could install a bunch of tools to make your life easier (shameless plug for my previous article). You could just start deploying apps and running them in production. Or, you might be thinking to yourself “How on earth am I going to secure this massive complicated thing that I just put out there in the cloud!?!?” That’s a valid question, and I am going to make an attempt to answer it in a set of easy-to-follow practical steps.

Disclaimer: I’m not writing a thorough guide on securing your clusters, and I’m not making any claims that this information is perfect. It’s a starting point, a way to get the brain juices flowing and open the door to a full security plan.

GKE

I started my Kubernetes journey entirely in AWS thinking it was the Bees Knees™. Then I found out about GKE (Google Kubernetes Engine) and promptly changed my mind. Both platforms are awesome and have their drawbacks, but if you’re just starting out, GKE is a great place to do it.

The latest defaults in GKE are pretty good and they’re always being improved, but there are some settings you should choose when setting up your cluster that will give you the ability to do nice security bits later on.

VPC-Native Cluster

The first thing to do, is turn on a VPC-Native network configuration. This is relatively new in GKE, and will be the default soon. It puts your cluster inside a VPC, much like you would do in AWS. It’s only one checkbox away, and totally worth doing:

Cluster Access

After you’ve done that, there is a set of checkboxes related to cluster networking that I will go through. The first is here:

As you look at this, you might be thinking “Didn’t this guy just tell us a while back that IP Whitelisting isn’t a form of security, and we should just stop doing it?” (article)r You would be mostly correct about that, and I tend to think that this step is largely unnecessary. However, as part of a larger security posture, this setting can be a great idea. This setting restricts access to your master nodes (and the Kubernetes API) to a specific set of IP addresses. This doesn’t mean that anyone on those IP addresses can magically just access your API because they still have to authenticate with Kubernetes to do anything. What it gives you is peace of mind that if a critical vulnerability in Kubernetes (see CVE-2018–1002105) comes up, you have a little breathing room to fix it. This naturally has usability implications around public CI/CD tools and remote workers, but if all of your expected traffic to your cluster comes from inside a single network, then by all means turn on “Enable master authorized networks” and set it to that IP CIDR block.

Network Policy

The third checkbox we want to consider is Enable network policy:

This box sounds awesome, and it largely is. It enables a network policy implementation called “Calico” that allows you to create Kubernetes network policy. In turn, this provides the ability to heavily restrict what things can talk to other things in your cluster. It doesn’t give a lot of benefit out of the box, but it opens the door to a world of security. If you plan to do advanced network policy, then checking this box in the beginning will save you some hassle.

Disable Legacy Authentication

The last set of boxes control authentication with the Kubernetes API:

Pretty soon, the default options are going to be sufficient, but until then you need to uncheck Enable Legacy Authentication, Issue Client Certificate, and Enable Legacy Authorization. This disables basic authentication and forces all users to use GCP authentication in order to gain access to the cluster. In addition, Google enables RBAC by default so that we can control who has access to what in the cluster. I will cover this in more detail later.

AWS (kops)

By default, kops creates a cluster that is internal to the VPC with nodes in a private subnet, masters in a public one, an ELB for API access, and ssh only available internally. In general, this is a fantastic network configuration and doesn’t need many changes. Hats off to the kops developers on that one. However, there are a couple of settings that need to be added when creating your cluster to maximize your security.

Cluster Access

First, you can enable a whitelist of IPs that have access to the masters (see the GKE section for my thoughts on this). You can do this in the kops cluster yaml by adding this tidbit and replacing your IP CIDR blocks:

spec:
  kubernetesApiAccess:
    - 203.0.113.0/24

Disable Anonymous Authentication

Another easy change you can make is to turn off anonymous authentication for the kubelet. From Kops Security:

spec:
  kubelet:
    anonymousAuth: false

Network Policy

If you want to enable network policy, you can do so by changing your network overlay. Calico or Canal are both good options that support network policy. I won’t cover it in detail here, but kops has a great bit of documentation on this subject.

Enable RBAC

Next, you want to make sure that RBAC is enabled in your clusters. This is the default in new kops clusters, but it’s worth checking the cluster spec for this:

spec:
  authorization:
    rbac: {}

Enable Audit Logging

And the last setting you want is to turn on audit logging. GKE gives you this by default, but in kops we have to add it ourselves. At Fairwinds, we use the following configuration, which comes from the Kubernetes Docs:

Cluster Security

Once you have the cluster built with all of these options, there’s even more you can do to enhance your security posture.

Use RBAC

It’s enabled now, so use it. The built-in policies can be useful, but you should think about your own as well. In addition, whenever you install a Helm chart, make sure that the very common rbac.enabled: true setting is on. This will create RBAC objects specific to that application. Go look at them and see what they do.

Use RBAC Manager to simplify the creation of RoleBindings and ClusterRoleBindings. This will enable you to create a simple CRD that binds Users/Groups/ServiceAccounts to Roles/ClusterRoles.

And finally, when you get deep in the weeds of RBAC and can’t for the life of you figure out why someone somehow does or doesn’t have access to something, use RBAC Lookup to look it up.

Use Namespaces Liberally

To quote a co-worker, “Namespaces are cheap.” Use them to separate things like infrastructure tooling and applications. This allows you to restrict access easily using RBAC and to limit the scope of applications. I will also make your network policy creation easier when you decide to do it.

Container Security

Lastly, we need to to secure the workloads that we run in the cluster since these are what will be exposed to our (potentially hostile) users. There are a lot of things that are default or common when running containers in Kubernetes that provide less than ideal security. Here’s a non-exhaustive list of things you can do to get started.

Don’t run multiple processes per container

Docker general best practices suggest a single process per container simply for usability and size reasons, and this is actually a great practice to follow for security as well. It keeps your attack surface small and limits the number of potential vulnerabilities.

Don’t run containers as privileged

Running a container or pod as privileged gives it the ability to make modifications to the host. This is a large security issue that is super easy to mitigate by just not doing it.

Don’t run containers as the root user

By default, containers run as the root user inside the container. This is easy to avoid using the pod specification to set a high-numbered UID.

spec:
  securityContext:
    runAsUser: 10324

Don’t use the default list of capabilities

Docker runs containers with a significant set of Linux capabilities by default, many of which your app might not require. You can see them in the source code. The following config will drop all Linux capabilities by default, allowing you to add only the specific capabilities your app actually needs:

spec:
  containers:
  - name: foo
    securityContext:
      capabilities:
        drop:
          - ALL

Scan your containers for vulnerabilities

Known vulnerabilities account for a large portion of breaches. Use a tool to scan your containers for them and then mitigate them. Anchore, Clair, and Quay are among my favorite tools, but there are others out there.

Look At KUBSEC.IO

This tool will analyze your deployment yaml and tell you what you should change in order to improve the security of those pods. It even gives you a score that you can use to create a minimum standard. The score incorporates all of the best practices that I have outlined above, as well as several more.

Here’s an example of a deployment with a score of 9:

Don’t Stop Here

There’s new stuff coming out all the time about Kubernetes and security. Go read it, and try it out. Just recently I read an article on the CNCF blog that had a good overview of security best practices and reminded me of some things that we should be doing better. Security is a complex web of multiple layers that can’t be solved with one tool, and it is never “done,” so please, don’t stop caring about it after you read this article.

Kubernetes 203 — Security Basics was originally published in uptime 99 on Medium, where people are continuing the conversation by highlighting and responding to this story.

A Kubernetes cluster is a powerful tool. It gives you the power to deploy your containerized workloads, automatically scale them, and schedule them across multiple machines. It can even open up a load balancer for your service to be exposed to the world (assuming you’re running in a supported cloud). Unfortunately, all of this functionality doesn’t come out of the box. You need DNS entries, path-based routing, TLS certificates, metrics, scaling, and role-based access control (RBAC). Over time at Fairwinds we have developed a set of tools that we run inside of every cluster which provide those various services. Our end goal is that any application can run in the cluster and have a human-readable address, a TLS cert, scale automatically, be able to utilize path-based routing, and only have the access that it needs. That’s no simple feat, with more than a few potential pitfalls along the way. This article should serve as a guide to taking a bare Kubernetes cluster and making it “fully operational.”

Disclaimer: This is intended as an intermediate guide. It assumes that you have a working Kubernetes cluster and understand most of the basic Kubernetes primitives.

Initial Setup

This guide is going to consist largely of installing tools and controllers into your cluster. At Fairwinds we use Helm, a Kubernetes package manager, to install most (or all) of the various tools we use. In order to use Helm, you have to install the tiller into your cluster. This can be done using the Helm cli, with a dedicated service account for tiller, like so:

In addition to Helm, this guide is going to reference a Kubernetes deployment. If you are reading this, you already know what a deployment and a pod are. For ease of following the guide, I will be using the following deployment of a simple Nginx pod and building on it:

Getting Traffic To Services

Let’s talk about how we get traffic from outside the cluster to your services running inside the cluster. There are a few different ways that Kubernetes allows us to do this natively, and we should explore those first.

NodePort Services

A NodePort service is exactly what it sounds like: it opens a port on all the nodes that can be used to route traffic to the Kubernetes service. It is defined in yaml like this:

And it ends up looking like this:

Notice we have an internal cluster IP, and that the port is defined as 80:32732. This indicates that when we try to reach any node on port 32732, we will be redirected to the service on port 80. It’s a useful construct, but it really only opens the door for an external load balancer to route the traffic. You don’t want to ask all of your customers to type 32732 at then end of our URLs.

LoadBalancer Services

In a supported cloud provider, a LoadBalancer service is awesome. It exposes a high port on all of the nodes in the cluster, and then it creates a cloud load balancer that uses that port to route traffic. The service definition is remarkably simple:

This creates a cloud load balancer in your cloud provider and attaches it to the port that it created. If we look at the service now, we see a couple of interesting things:

First, we see that there is an external IP address marked as <pending> because our cloud provider is still creating the resource. Second, we see that the port listed for the service is 80:32732. This indicates that the service has exposed a NodePort that will be used as the listener port for the load balancer.

LoadBalancer services are powerful and highly configurable with cloud-provider specific annotations, but they have a few limitations. The biggest issue is that every service you expose creates a separate load balancer. In a world of tens or hundreds of microservices, this adds up a to a lot of cloud load balancers. LoadBalancer services also don’t provide opportunities for path-based routing. Again, in a world of microservices (or even regular services), this might be a non-starter.

Ingress

Given the limitations of NodePort and LoadBalancer services, we need something a little more powerful. The Kubernetes developers anticipated this need and created the Ingress object. Ingresses require that you run a controller in your cluster to handle them, and they are a little more difficult to get running right out of the gate, but the payoffs are huge.

As previously mentioned, in order to use Ingress we need a controller. There are several controllers out there, such as Kong and HAProxy. At Fairwinds we have found ingress-nginx, an Nginx-based controller, to be the easiest to use and one of the most complete solutions. There are many ways to install it, but we prefer to use Helm:

This will create the Nginx controller and expose it to the world using the now-familiar LoadBalancer service:

This service points to a set of controller pods that are running Nginx. Now we can create objects in Kubernetes called Ingresses that will configure Nginx to route traffic to our services inside the cluster.

Every service you deploy that needs to be exposed outside the cluster will now include an Ingress definition. Ingress definitions are also quite simple and look something like the following snippet:

Notice that it routes to the service we created. This tells Nginx to route traffic to that service when it comes into the cluster with the matching hostname. This is how we get path- and name-based routing. If we dig into the ingress controller pod and look at the config for Nginx, we will see a very familiar Nginx server block which corresponds to our new ingress.

Like the LoadBalancer service, Ingresses can incorporate very detailed configuration using annotations. These annotations are Nginx specific, and can configure different options in the controller.

All of this means that we now have a way to run tens or hundreds of services behind a single Nginx proxy (or group of them), and these proxies are configured using easy to deploy Kubernetes objects. We can even use this to create TLS certificates and DNS, as we’ll see later. Right now we have a single cloud load balancer that handles TCP traffic to the controller, and we handle routing from inside the cluster. Here’s a little diagram to bring it all together:

DNS Entry Creation

Since we are using path- and name-based routing, we are going to need to create DNS entries. In the spirit of using controllers and other Kubernetes-native constructs, Fairwinds uses a project called external-dns. This controller will watch for annotations and certain types of objects and create DNS entries based on them. It is also deployed with Helm:

Note that credentials for your DNS provider will need to be specified as well, which depends on which DNS provider you are using. See here for more details.

Now when we create ingresses with DNS names, the external-dns controller will update our DNS provider with the IP address of the ingress controller.

Encrypting Services With TLS

Now that we have HTTP traffic to our services and easily accessible names, we want to secure them. HTTPS has become the de facto standard now that search engines optimize for it and browsers give ugly warnings if it’s not there. Traditionally this has been a pain point for operations teams. Back then, we had to generate the certs and do validation (sometimes from a manual portal), and then the certs still had to be deployed. Depending on the application we had to update application code or restart web servers. In the modern age, we have a few different options.

Cloud Provider Cert Storage

Amazon provides Amazon Certificate Manager (ACM). Combined with a LoadBalancer service and a special annotation, we can utilize an ACM cert to terminate TLS before it gets to the cluster. ACM automatically renews the certificate if you generate it using Route53 DNS. In a similar fashion, the ingress controller can incorporate a wildcard ACM certificate with its load balancer. This means that any Ingress we create that uses a domain in the wildcard gets TLS for free. This is a good option for a small number of services as long as you are comfortable with a wildcard. Some security policies don’t allow for it, and sometimes you want more than one subdomain. For another auto-validating option, we look further.

Let’s Encrypt

With the rise of cloud computing and privacy concerns, Let’s Encrypt set out to create a Certificate Authority anyone can use free of charge and fully automated. They have a specific protocol that allows you to validate and generate a certificate automatically and programmatically. Many implementations of the protocol have been done, but we at Fairwinds focus on cert-manager. This tool utilizes a custom controller inside of Kubernetes that requests and maintains certificates from Let’s Encrypt. This is coupled with a shim that watches for new Ingress objects and automatically generates certificates for them.

What all of that means is that you can deploy the cert-manager and not worry about TLS certificates ever again. Of course, it’s a little more complicated than that, but once deployed it makes management of certificates seamless.

In order to deploy cert-manager, we use Helm again:

Once the controller’s running, there are a few more pieces that need to be set up. There are two ways to do domain validation for certificates. We prefer to use DNS01 where possible at Fairwinds. In order to do this, your cluster nodes (or the cert manager) must have access to modify your DNS provider’s records. This is outside scope for this article, but it can be done with node roles in your cloud provider. The other option is to create a service account that you would then use in the following step.

Next you create an Issuer or ClusterIssuer which is responsible for configuring your Let’s Encrypt account and setting up the validation method that you’re going to use. For this guide I will use a ClusterIssuer and connect it to Let’s Encrypt. This is done by creating another Kubernetes resource:

There are a few things going on here:

1. It’s using Google Cloud DNS for validation
2. It’s using a service account for permissions to update DNS. The service account credentials are stored in a secret called dns-gcloud-config
3. The email address will be your Let’s Encrypt account name. Renewal email warnings will go here
4. This points at the Let’s Encrypt prod endpoint, so it will make valid certificates

Once you apply this resource, the cert-manager controller will attempt to set up your Let’s Encrypt account. If you do a kubectl describe clusterissuer letsencrypt-prod, you’ll see a few lines like this at the bottom of the output indicating your account was registered:

Now that you have an issuer and we have the ingress controller, we can redeploy our Ingress object to utilize cert-manager:

Notice the annotations that specify an ssl redirect and which ClusterIssuer to use in addition to the TLS block at the bottom of the ingress. There is also a secret name specified that cert-manager will use as the name for the certificate. We can verify that all of this is created like so:

So now we have a functional ingress with automatic TLS encryption routing traffic to our cluster. This leaves one more piece of the puzzle in order to have a fully operational service in Kubernetes.

Scaling Applications Using Metrics

I’m going to lump scaling and metrics together because we can’t scale an application without some sort of metrics to scale on, and they can be configured quickly and easily together. Kubernetes has a built-in mechanism called a horizontal pod autoscaler that can be used to maintain the number of replicas in a deployment based on metrics. In order to do this, we have to expose the metrics to the Kubernetes API. Unless you’re on GKE, which gives you this automatically, the easiest way to get metrics is to deploy the metrics-server into the cluster. This is very simple using Helm:

Once the controller starts and metrics are populated, we should be able to see resource utilization of pods and nodes like so:

With metrics available, we can create a horizontal pod autoscaler (HPA) for our deployment. The HPA is defined as another object and looks like this:

After a few minutes you can look at the HPA and see the current status:

This setup will watch the CPU usage of the pods and try to keep them at or below 80% utilization based on the CPU limits set on the deployment (see the original deployment). If the utilization goes too high, the HPA will scale up, and if it goes down for a time, it will scale down. This behavior can be changed to use any metric via a custom metrics provider. Tuning this correctly will allow your deployment to handle many varying traffic and load problems.

Scaling The Cluster

Scaling pods horizontally is great and allows for dynamic traffic handling, but it doesn’t control how many nodes are in the cluster. As we add more and more pods, scaling them up, we are going to need more nodes to handle all of the pods. This will become obvious when you see a bunch of pods in a Pending status; when you do a kubectl describe pod <pod-name> you’ll see a message about not being able to schedule the pod. We handle this by utilizing cluster autoscaling. The cluster autoscaler project will scale up if new pods cannot be scheduled, and it will keep an eye on node utilization, scaling down if it sees an opportunity.

Installation looks very different depending on which cloud provider you are using, but I briefly will cover AWS and GKE setup.

GKE

This one is really easy. GKE runs the cluster autoscaler by default if you turn autoscaling on in your node pools. You can do this in the console, or using whatever code you used to set up your cluster:

AWS

This again depends on how you created your cluster, but at Fairwinds we use kops. No matter how you built your cluster (excluding EKS), you still need to install the cluster-autoscaler. We use Helm to install the autoscaler using auto discovery of nodes.

This requires modifying your kops cluster and instance group definitions. This is beyond the scope of this article, but it is well documented here.

Permissions — RBAC

Managing RBAC (role-based access control) in Kubernetes is difficult. The cluster you built most likely has it enabled by default, and you probably haven’t configured it at all. This tutorial has already made use of RBAC inside the Helm charts that we deployed.

Out of the box there’s a bunch of resources that you can define:

• serviceaccounts
• clusterrolebindings
• rolebindings
• roles
• clusterroles

Keeping these straight is confusing, and modifying permissions usually requires multiple sets of definitions. Fairwinds utilizes a controller that we wrote to make it simpler called rbac-manager. We can install it with (you guessed it) Helm:

We can now create an object called an rbacdefinition in order to manage our permissions and service accounts. Let’s go ahead and create one for our CI/CD system to use:

Applying this will create a service account called ci and bind it to the cluster role cluster-admin. In the future we can generate a kubeconfig file for our ci system using that service account. Going forward we can add to this in order to finely control all permissions for users and service accounts in the cluster.

That Was A Lot

You just installed a TON of tools into your cluster and added a lot of functionality. What did we just add?

• Ingress Controller — For routing and TLS termination into the cluster
• External DNS — Manages your DNS records for your ingresses
• Cert Manager — Generates and maintains TLS certificates for the ingresses
• Metrics Server — For enabling the use of Horizontal Pod Autoscalers
• Cluster Autoscaler — For managing cluster size based on pods
• RBAC-Manager — For managing your cluster permissions

All of these required one or more Helm charts to install, and may require different values depending on customizations that you want to make. It can be frustrating to run these commands and maintain these values files, especially if you manage multiple clusters. Fairwinds utilizes a homegrown tool called Autohelm to manage all of these charts. It allows you to maintain a single file that defines all of the charts you want to use. There are examples of all the different charts being deployed in the examples.md.

Something Something Great Responsibility

Now you have the awesome power of a “fully operational” Kubernetes cluster. Go forth and deploy services that are auto-scaling, highly available, and TLS encrypted. Please hit me up @sudermanjr with comments or requests for future topics.

Kubernetes 202 — Making It Fully Operational was originally published in uptime 99 on Medium, where people are continuing the conversation by highlighting and responding to this story.

In the last several years, I’ve seen an alarming number of requests to implement a system where we allow access based on the user’s IP address. In my experience this creates a false sense of security and causes a significant amount of pain, specifically in cloud environments. But before I go on, a brief history of the internet and security to give context.

A Brief History of the Internet¹

• 1983 — Vint and Bob create TCP/IP V4 and it is implemented in ARPANET
• 1985 — People start hoarding IPv4 CIDR blocks
• 1999 — Cloud computing becomes a thing
• 2002 — Static IPs are limited and start changing frequently

A Brief History of Security¹

• 1988 — People realize that static IPv4 addresses are a thing
• 1990 — Companies use whitelists to allow traffic according to these IPv4 addresses
• 1991 — Companies think this is a good idea

I may have missed some stuff here. You get the point. IP whitelisting became the first security implementation that every network admin deployed for years. More frequently (and more terrifyingly), they just stopped right there.

What’s wrong with that?

Let’s talk about the implications of using IPs as your only security measure. First, IP spoofing is a thing. Of course this will not allow bi-directional attacks, but it can be used in DOS attacks. Secondly, BGP hijacking can be used to attack these types of defenses.

These are fairly sophisticated attacks that would require a serious attacker, however they make a good case for why this should not be your only security mechanism.

An even bigger issue with IP filtering is that the modern use of cloud computing makes this type of security measure entirely untenable. Most cloud instances don’t use static IP addresses by default. Cloud providers only have a limited amount of IP space, and they aren’t going to just hand it out to everyone. The much more common use case is that every time a resource is created, it gets a random new IP, or even better, it gets an internal address and is hidden behind some form of gateway. With good reason, cloud providers are urging people to use models that consume fewer IP addresses.²

This means that we need to stop relying on static IP addresses as a security mechanism. </rant>

Isn’t it better than nothing?

In the world of tech, we frequently talk about security by saying, “Anything is better than nothing.” You can’t really argue with this statement because of how vague and obvious it is. I want to encourage everyone that works in technology to stop saying this and instead start asking “How do we implement security that is good enough?” This question encourages us to reconsider our entire strategy and decide if it’s enough to protect the value of our business. A strategy might include IP blacklisting on a large scale to avoid traffic from known dangerous actors, or it might include any number of other measures that by themselves are inadequate but put together provide good security. Let’s get rid of the defeatist attitude of “better than nothing” and focus on security that’s “good enough”.

¹Please note that the dates in the article are almost entirely fictional and should not be taken as fact

²AWS documentation specifically states that IPv4 addresses are scarce. https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/elastic-ip-addresses-eip.html#using-instance-addressing-limit

My IP Is Not My Password was originally published in uptime 99 on Medium, where people are continuing the conversation by highlighting and responding to this story.