In Kubernetes 1.23 the new ephemeral containers API went in to beta and in 1.25 it became stable. Ephemeral containers or debug containers as it is also known as, makes it's possible to inject a container into an already running pod without restarting it. This is very useful when you want to debug your application since the ephemeral container can provide tools that you don't want in your application container.

In this post I thought we could go trough how to profile a running container in Kubernetes.

How sure are you that you have close to 0 critical CVEs in your Kubernetes cluster?

Just like for all companies today security is top of mind for Xenit and we try to come with a solution for this question.

At the time we were already scanning our images in our CI/CD pipeline at creation time using Trivy, but what about new CVEs that gets disclosed after the initial image build?

The increasing rates of cyber crime (by some measures, cyber crimes now outnumber all other crimes put together) which makes it harder for companies to protect themselves. The faster we can fix relatively simple problems like patching a CVE on container level the more secure we will be.

Xenit is hosting a number of Kubernetes clusters for our customers and we want a quick way of visualizing CVEs on a platform and a per customer basis. We want to achieve this without having to jumping around to different clusters and run some script to find out the answer to this question.

HTTP has become the de-facto standard transport protocol for programmatic communication in software-as-a-service offerings. This mostly entails publishing request-response style APIs. We often refer to these APIs as "RESTful APIs":

[When a] request is made via a RESTful API, [the response is] a representation of the state of the resource[.] -- https://www.redhat.com/en/topics/api/what-is-a-rest-api

Let's decrypt that: "representation" has come to mean JSON, while "state" refers to those ubiquitous (and unwieldy) relational databases and "resource" is an object from our domain model.

The literature on API design will exhort you to analyze the problem space and consider your design choices carefully. Indeed, design choices will significantly impact the lifecycle of APIs that are part of a software-as-a-service offering. However, when designing a software-as-a-service API, we do not really know the details of future usage. The goal must therefore be to maximize our freedom to evolve the APIs without having to change the formal or informal contracts that regulate their usage. The API should become a facade behind which we are free to evolve the implementation.

This post proposes and motivates a set of guidelines for RESTful APIs (and by extension their contracts) intended to maximize their life span and support rapid evolution throughout it. The post focuses on organizations that want to provide commercial software-as-a-service offerings, though many of the guidelines have wider application.

Attempting to debug a Pod and realizing that you can't install curl due to security settings has to be a meme at this point. Good security practices are always nice but it often comes at the cost of usability. To the point where some may even solve this problem by installing debug tools into their production images. Shudders.

The Twelve-factor app is a methodology for building software-as-a-service apps that was first formulated by developers associated with Heroku. It's been ten years since the first presentation of this methodology. Despite the criticism that it is only applicable to Heroku and similar webapp services, it remains a relevant yard stick for software-as-a-service development. Some of its tenets have been incorporated into Docker and thence into OCI, effectively making them the law of container-land. This blog post looks at each of the twelve factors and tries to evaluate whether they remain relevant or whether they need updating.