Latest Posts

There are many options for building and deploying Go applications using containers and believe me, I have tried most of them on my journey to find the right balance of fast build times, small containers, and security. After trying lots of different options, I believe I have landed on the optimal solution. My first priority is security. I want to make sure the container only contains the things I need to run my application and runs as a non-priveleged user.

One the drawbacks of debugging go code with VSCode is that when you make a change, the project should recompile automatically and start debugging. Enter air. Air provides live reload for go apps and has made developing go applications much easier. As our applications have gotten more complex, we wanted to integrate air with the VSCode debugging process. It was a bit tricky to setup, so I thought I would share our configuration.

Over the last 2 years, I have been doing most of the development at Takt in Go. We chose Go due to its versatility for web services and background process code. Our team uses VSCode as our editor of choice and have tweaked our VSCode setup to meet our needs. In a future blog post I will talk about how we use Github Actions to deploy Go containers. Obviously, “Best” is subjective and each editor setup needs to fit the individual and/or the team.

If you are running in a corporate environment or are migrating a Kubernetes cluster from an overlay network to Amazon EKS, you most likely have a question: “What do you mean the Pods and EC2 Instances are given IPs out of the same CIDR range?” First, this is perfectly natural. Amazon EKS leverages all of the features, security, and simplicity of the Amazon VPC. This is an advantage for customers becaues you can leverage all of your existing security tooling that is running within your network and simplify routing between pods and your wider network.

JupyterHub is a multi-user notebook that enables multiple users to develop, research, and create. In this post, I am going to cover deploying JupyterHub to Amazon EKS with single user persistent storage backed by Amazon EBS and TLS termintation using the AWS Certificate Manager (ACM). Before we dive in, make sure you have eksctl, kubectl, and Helm installed on your local machine. We will be using these tools to deploy the Kubernetes cluster and JupyterHub.

In many enterprise environments, all outbound traffic needs to be routed through an HTTP proxy. This requires setting the http_proxy, https_proxy, and no_proxy environment variables inside the pods. This can be difficult to manage. Below is a simple way, to configure the proxy settings in a central location for all pods. Run the following command, updating the values with the values that apply to your setup. This will create a Kubernetes Secret in the default namespace (you will need to create this config map in all namespaces where you deploy pods).

Amazon Elastic Kubernetes Service (EKS) recently launched in AWS GovCloud (US) enabling public sector customers with FedRAMP, DoD CC SRG, ITAR, etc to run fully-managed Kubernetes clusters. Amazon EKS in AWS GovCloud (US) has one difference from it’s standard region counterpart deployments. When a cluster is in Private Mode the private IP addresses are not advertised over public DNS. In the standard regions, the private IP addresses of the Kubernetes API server are advertised over public DNS to integrate with on-premises DNS providers.

In a previous post, I covered how to enable FIPS 140-2 mode on hosts and within containers. Organizations building applications for FedRAMP or DoD CC SRG compliance need to enable end to end encryption of data in transit. In a containerized environment, this can be difficult. Most containerized applications terminate TLS at the cloud load balancer, such as an Application Load Balancer. This post will walk through terminating the TLS connection within the Pod or Task using NGINX.

In my last post, I covered how to deploy a Kubernetes cluster to AWS GovCloud (US). In this post, I will cover how to add authentication using AWS IAM using aws-iam-authenticator. The AWS IAM Authenticator runs a DaemonSet on all of the master nodes within the cluster and uses a webhook to integrate with the Kubernetes API Server. AWS IAM Authenticator also runs on your local machine via your local kubeconfig to create a temporary token used for authentication.

AWS GovCloud (US) is an isolated instance of AWS designed for customers with specific US compliance requirements. AWS GovCloud(US) does have some differences from the commercial regions when it comes tooling. AWS GovCloud (US) gives government customers and their partners the flexibility to architect secure cloud solutions that comply with the FedRAMP High baseline; the DOJ’s Criminal Justice Information Systems (CJIS) Security Policy; U.S. International Traffic in Arms Regulations (ITAR); Export Administration Regulations (EAR); Department of Defense (DoD) Cloud Computing Security Requirements Guide (SRG) for Impact Levels 2, 4 and 5; FIPS 140-2; IRS-1075; and other compliance regimes.