URL reference: https://kubernetes.io/docs/concepts/containers/images/#use-cases
DateReviewed: 2024-01-01
Description: This is the Kubernetes docs, specifically the area on repositories. It's actually a little confusing, because one of the use cases is actually an example of not needing a private repo -- everything is open source code. It then goes on to explain how to set up a private repo and what controllers you need to ensure you arbitrate access correctly -- you may not want certain pods to run outside of specific nodes. It's a few paragraphs inside of a much larger doc, but the private registry parts are decent.
BottomLine: Good explaination of how to run private repos for images in Kubernetes
==
URL reference: https://twitter.com/hisomraj/status/1742040731534172404
DateReviewed: 2024-01-02
Description: It's an inforgraphic, so let's go. It's on Kubernetes security, and tells you what not to ignore. It covers RBAC, Pod Security, Network policies, Encryption and Logging as seperate points. Each point has 2 bullets, so not too much is covered on each area. All of the points are very high level, and the illustration level is not very high for a visual medium. There points are all solid, so it's a good quick overview.
BottomLine: Infographic that is a decent high-level toe dip to Kubernetes security
==
URL reference: https://fixyacloud.com/kubernetes/exploring-the-power-of-kubectl-dry-run-client-and-server-command-examples
DateReviewed: 2024-01-03
Description: Our article is going to tackle what the "dry run" command is and how to use it. We start with a definition, where they explain the dry run command shows you what the impact of your change would be, without actually making any actual changes to Kubernetes resources. We then review the client-side version of dry run, which just shows you what commands would be sent to the back end. The more interesting bit is sending them to the server, which is done with a different flag, and we'll be told how this would impact the cluster. They then explain how to run through the process, and include a couple of quick examples. It would be helpful if they'd done a bit more on the example side, but this is adequate for an intro.
BottomLine: Decent intro to the Kubernetes dry run command and some examples
==
URL reference: https://www.devopsroles.com/installing-kubernetes-using-kubeadm-on-ubuntu/
DateReviewed: 2024-01-04
Description: This article will walk us through installing Kubeadm on Ubuntu. We're going to be using 2 worker and 1 master nodes in this scenario. The then walk us through some config details for the setup, and mention we need to disable swap and set up bridging (which then include instructions for). We have to install Docker, to have a container runner, so they take us through that, including having it run. Next we go through the Kubernetes bits we need, including Kubeadm, Kubelet and Kubectl. Once the configs are done and everything is installed, we start our Kubernetes for the first time, with "kubeadm init". There is another bit of housekeeping on the master, and then we start spinning up the workers, by cut and pasting the output from the master spinup. Finally, we can check that our cluster is running. Now, this is a basic guide, but does a good job of touching all the points.
BottomLine: Good walkthrough on how to get Kubernetes installed on Ubuntu
==
URL reference: https://www.tigera.io/blog/deep-dive/deploy-multi-tenant-red-hat-openshift-clusters-with-calicos-namespace-and-workload-isolation/
DateReviewed: 2024-01-05
Description: Containers good but security bad to start, what a unique opening. This time, we're going to focus on Calico to get our security helping done. Typically all of your pods share one network segment, and what we're doing here will produce isolated micro-segments. Let's dig in. For Kubernetes, we use the CNI, or Container Network Interface which sets up the pod networks. CNIs work to plug the pods in, but don't contain a policy engine -- K8s comes with a native one that allows network policies to be set. Our area here is OpenShift, so we'll use that to create our Network Policies through a YAML file. We can code the YAML directly, or the suggestion is to you OpenShift's GUI to create one. We're then introduced to Calico, and they have a 5 paragraph blurb about what Calico does. So, spinning up a default OpenShift cluster starts 60 namespaces and services and has hundreds of pods running -- ouch. Helpfully Calico has a graph to show you the interconnections in a visual way, and our authors tell us that not every pod should be able to talk to all the others -- but that is the default. There is a way to gather the comms paths and view proposed policies, but it's important a DevSecOps person review them. They then do show the visualization tool does show traffic and it's associated policies, which allows you to ensure all traffic is covered properly. It's a bit complicated, but it does seem like an interesting approach.
BottomLine: Decent mid-level walkthrough of a microsegmentation approach to Kubernetes
==
URL reference: https://www.kubernetes.dev/blog/2024/01/05/kube-proxy-non-privileged/
DateReviewed: 2024-01-06
Description: Our post here will show how to run kube-proxy in a seperate container. Usually, to run kube-proxy we need our container to be "privileged", but usually we don't want our workloads to run in such privileged containers. So, what to do? In this case, they are leveraging the fact that in init containers we can set sysctls and then not need the container to run with privilege. They then run through the YAML that would be needed to set up such a situation, and explain that by using the --init-only flag it has the desired effect. Now personally, I've only used kube-proxy for quick checks or debugging, but I see where it might be helpful -- but I think best practice would be to expose a service. Still a neat technique.
BottomLine: Interesting way to run Kube-proxy on Kubernetes without needing privileges
==
URL reference: https://www.bsmithio.com/post/baremetal-k8s/
DateReviewed: 2024-01-07
Description: This is a guide to getting a specific version of baremetal K8s working. They are going to install ono top of Ubuntu 20.04, and we start with a recent version of Docker. They then pull down things to support, like the CLI and containerd. We tweak the configs and start Docker, then install the Kubernetes utilities, including kubectl, kubelet and kubeadm. We then set up the configs (and decide if we want to run K8s as root), and then set up the Network bits. They then explain how to enable running pods on the master node, if you should want to run a single-node cluster. Next they explain how to set up worker nodes, including how to join the cluster. They then go through the setup of MetalLB, so you can have a non-cloud based LB. The final step is the Ingress controller, which allows traffic to come into our cluster. To test things, they show us how to create a test app and deploy the associated pod. They then explain how to connect ingress to our app, and how to get things working with our hosts file. They also show how to get TLS working, which is helpful. As extras, they include refs to external-dns, cert-manager and k8s_gateway. Overall, a strong guide.
BottomLine: Good walkthrough on setting up a local bare metal Kubernetes
==
URL reference: https://thenewstack.io/what-is-ebpf-the-ultimate-guide/
DateReviewed: 2024-01-08
Description: This article is on eBPF, the extended Berkeley packet filter, and what you can do with it. It's an extension that allows things and is run in the kernel, but it is also sandboxed so that it is run with constraints. Basically eBPF allows us visibility to any and all system calls, and that allows an amazing amount of observability, all else it can do aside. We are given a bit of background, some history on the development, and a bit of a high-level on the uses. They then pull in the BPF, which was a network-focused component that allowed for things like rules and rewriting. There are another couple sections where handwaving goes on. They talk a bit more about use cases, and it's a good high level intro, but I was hoping for a bit of a dive on the workings of eBPF.
BottomLine: Good high level toe-dip on why you might want to use eBPF on your Kubernetes cluster
==
URL reference: https://medium.com/@jamesoluwaleye/mastering-containerization-with-docker-and-kubernetes-in-the-cloud-bc9ee2976c45
DateReviewed: 2024-01-09
Description: We're going to learn a bit about Docker and Kubernetes, fun fun! We start off with instructions and a bit of Docker nomenclature, so we are all on the same page. Next up is building and managing Docker images, which we'll need to do so we can actually run something. They touch on using the Docker build command, and a bit about how layers work. It goes through the steps, and even has a short section on troubleshooting the build process. We then move to Tagging and versioning, which is important but often overlooked. They run through an example with Docker tag, and explain how to add tags and versions that make sense. They talk about tagging best practices, and show how to put your taggged image into a repository. We then do a bit of a dive into the Docker registry, Docker Hub, which is one of the larger image repositories out there. After that, they look at image size and how to cut things down, including multi-stage builds and using layers and caching to your advantage. Now we move on to Kubernetes, where we can orchestrate our containers. They do a bit of terminology again, and then explain a YAML config for creating a container in the cluster. A short section on Load balancing and service discovery is followed by a long section on security. I love the Docker section but the K8s stuff seems a handwave.
BottomLine: Good walkthrough of how Docker works with a quick tour of Kubernetes
==
URL reference: https://dev.to/mattiasfjellstrom/kubernetes-101-security-concepts-2f4f
DateReviewed: 2024-01-10
Description: This article is part of a series on Kubernetes, and this part is focuses on K8s security. This is a more hands-on approach, and they dive into specific examples to aid understanding. So, first up we are talking about networks, and they explain the plumbing that NetworkPolicy needs a corresponding controller to enforce it. They then look at a specific Network Policy, and go through a YAML config file and break down what the things mean and do. Staying on the network theme, they examine a Ingress and Egress policy, doing a similar breakdown. They then pivot to ServiceAccounts and how they can be use to restrict what a Pod can do. They give us a bit of background, then show how to apply and check that the ServiceAccount has taken effect. To have effect, we have to assign a ServiceAccount to a Pod, and that will enforce restriction associated with the SA (if any). We then move on to RBAC, and again there are some supporting discussions and we are taken through a YAML config with an explaination. They also loop in SecurityContext and explain a bit about it and how to apply it. Overall a decent walkthrough of K8s security concepts.
BottomLine: Good mid-level walkthrough of a few Kubernetes security mechanisms and concepts
==
URL reference: https://www.tigera.io/blog/deep-dive/5-tips-for-better-kubernetes-network-security-policy-design-for-workloads/
DateReviewed: 2024-01-10
Description: So we start with K8s amazing growth, but has security issues. Seems here our focus will be on Network, and Calico in specific. Our first tip is solid - scope your policies correctly, and in the text they ask - who will be protected by this? They follow with an excellent example where a policy intended for a specific pod is attached to every node in a namespace, causing extra work for all traffic to get through. Our second tip alludes to Tier design, and this has to do with a logical division of how your protections are arranged. In their tier recommendations, they have a security tier which might apply cluster wide, and other tiers (like Application) which may only apply to certain pods. The idea here is to streamline traffic examination. Tip 3 is to use networksets, which are network groups in your cluster. The gist here is to allow you to allow some IP ranges access to places like the Internet, while restricting other ranges -- think microservices that talk to an external provider vs. internal services. Tip 4 applies to anything -- watch out for unused things, in this case, policies. They point out there are spots these are intentional, but do surface a way to check for the existance of unused policies. Our last tip is to observe, and in this case they mean watch, verify and understand how your policies are working. They show some GUI places to see them, but there are also some command-line ways to get this info. Overall great advice and helpful examples to get you started.
BottomLine: 5 solid tips with examples to improve your Kubernetes network security
==
URL reference: https://cloudnativenow.com/features/the-best-kubernetes-tools-for-2024/
DateReviewed: 2024-01-11
Description: This article will do a survey of the best tools of (the start of?) 2024, so let's go. They have divided things up into 7 areas, so let's see how that falls out. They do a paragraphy on each area, and then a short paragraph on each tool. First up is deployment tools, and we touch on Helm and Kubespray. Next is monitorying tools, and we see Prometheus, Kubewatch, Grafana, and K8s dashboard. We finally come to CLI tools, and they include kubectl, etcd, and K9s. Swiftly on to Security tools, we see kube-bench, kube-huner, and Kamus. Next up is dev tools, and they list Telepresence and Skaffold. After that we have gateway solutions, which is traffic management, and it includes Edge stack. K8s component tools are Kubelet and Kompose, then Cost management peek at Kubecost and Loft. I'd liked for them to give a bit more coverage to the tools, but the article seems more focused on quantity and mentions then deep dives. Still, a good place to start researching.
BottomLine: Very shallow survery of lots of various tools that work with Kubernetes
==
URL reference: https://securityboulevard.com/2024/01/why-context-matters-in-kubernetes-security/
DateReviewed: 2024-01-12
Description: We start with security having context, as vulns matter depending on what you are running. From that starting point, we dive into K8s security, which can be complex. They point out there are many K8s security tools, but you have to apply the tools to reap benefits from them. They divide K8s into 6 information "streams", and talk a good paragraph about each one. They tackle K8s API, audit logs, RBAC settings, image vulnerability info, node info, and eBPF app observability info. They then show how attackers might benefit from this info through use cases, and how defenders can mitigate attacks. Overall a good considered piece.
BottomLine: Well done piece that argues for a re-examination of your security appraoch with regards to cloud and Kubernetes
==
URL reference: https://medium.com/techbeatly/exploring-kubernetes-1-29-with-kind-a2704e1c729d
DateReviewed: 2024-01-13
Description: We start with an explaination of what Kind is, namely Kubernetes in Docker. It's a big paragraph, so does decent detail of what this means. The main gist of this article is checking out the current latest 1.29 version of K8s, but first the article takes us through spinning up Kind to take a peek at it. They give a link to setup instructions, and then show how to spin up and delete a cluster in Kind, which is kind of neat. They then show how to write a kind config file, and spin up a 4 node cluster with the contents. Next, they show how to flag a specific version of K8s to use. Finally, they show how to access the cluster. I think it would be helpful to take a 1.29 feature for a drive, but this feels like a more generic article which may be reworked for each release, and is on the lean side. Still, it makes me want to check out Kind.
BottomLine: Decent walkthrough on setting up a Kubernetes cluster on Kind
==
URL reference: https://www.esecurityplanet.com/products/container-and-kubernetes-security-vendors/
DateReviewed: 2024-01-14
Description: This is a comparison of security tools and offering, because Kubernetes is a target since it is popular. They rattle off a list with some "bests", and then give us a huge chart, with pricing and some indication of what each product does. If that were it, it wouldn't be awful, as you get some ideas where things are, but for each vendor/product, they have a section with background, pricing, features, and pros/cons of each product. Then after all that, they go through a short piece on features you need in a K8s security solution, as well as the benefits you should expect out of such a solution. They then go through some recommended approaches, and finally go through their methodology. Definately a high level approach, but a good breadth of tools are touched on and the approach is decent. Excellent place to start your K8s security journey.
BottomLine: Good starting place for Kubernetes security, which covers many tools and has good approach and recommendations
==
URL reference: https://devopscycle.com/blog/the-ultimate-docker-cheat-sheet/
DateReviewed: 2024-01-15
Description: When I think of a cheat sheet, I think of a single or possibly double-sided paper crammed full of ALL the info about a specific topic. Is this that? Yes. But No. There is a sheet upfront, but there are a large number of questions and paragraph and sometimes multi-paragraph long answers, which help to understand how to build images, do multipart builds, and store images. Recommended reading.
BottomLine: Good cheatsheet with a walkthrough of good Docker questions and detailed answers -- recommended
==
URL reference: https://medium.com/@maheshwar.ramkrushna/securing-apache-redirecting-and-enhancing-security-with-proper-configuration-63e9f4da2fe8
DateReviewed: 2024-01-16
Description: Very simple approach here -- focus on the security of the Apache web server. It's a step-by-step walk through so they start assuming zero knowledge and even show you where your config file (might) live. In this case, for some reason they redirect all traffic to port 8809 (from 80 and 443). I thought they were going to do this internally, but this is an explicit redirect sent to the client web browser. They do talk about certs and security headers, and explain how to turn off directory listings. 
BottomLine: Good toe dip into Apache security pieces - but just a start
==
URL reference: https://cloudnativenow.com/topics/cloudnativedevelopment/overcoming-chaos-in-kubernetes-certificate-management/
DateReviewed: 2024-01-17
Description: We start with K8s being a dynamic environment, so tracking and keeping certs up to date is hard. They postulate that large K8s clusters can be a challenge, and that different services might have different needs. Seems like we're focused on enterprise K8s run at a huge scale. Without talking about approach, we have best practices tossed at us -- from general security on K8s, not certs. While there are some solid bits in this multi-point interlude, only one talks hand waved-ly about certs. We conclude with a fluffy paragraph about how a few areas of an org have to work together. So, while having a great argument and possibilities, it's clear that whoever wrote this had no understanding of CAs or what is actually needed to roll out Certs at scale, so added general best practices and hoped for the best?
BottomLine: Great premise but Terrible article -- no actual approach or solutions are put forward on Certificate management
==
URL reference: https://www.tenable.com/blog/k-is-for-komplex-key-kubernetes-considerations-for-security-teams
DateReviewed: 2024-01-18
Description: We start with Kubernetes having huge uptake, but - wait for it - isn't secure as it might be. Shocking. The focus is to "take leadership", which I guess means proactive management of the clusters? We go through a couple paragraphs of scary stats and complexity is bad, then they reveal their basic thesis - there are 3 main issues in K8s land - ephemeral nature, default insecure, and application of policies. Each heading has at least a few paragraphs of high level verbiage explaining what it is and why it's important. While it's an okay intro, it's lots of very high level stuff and a bit handwavy on the actual doing.
BottomLine: Okay high level toe dip on Kubernetes security, but lacks good advice on how to implement
==
URL reference: https://romaricphilogene.substack.com/p/platform-engineering-8-designing
DateReviewed: 2024-01-19
Description: This article is about building a developer-friendly interface, so your deployment pipeline works better. I like this, as the article doesn't tell you exactly what to build, but says you need to build something that will work for your devs, and integrate the tools they use. It talks about various options, and explains that its an ongoing process where you craft the interface based on feedback and iteration. Okay, there is a product pitch, but it's only one option and done late in the game. Overall, a good unique approach.
BottomLine: Unique approach to building an Interface for your developers to use as part of their deployment chain
==
URL reference: https://dzone.com/articles/revolutionizing-kubernetes-with-k8sgpt-a-deep-dive
DateReviewed: 2024-01-20
Description: We start off by talking about K8s rapid evolution, and we pivot to how AI can help out. The focus of this article is a package called K8GPT. While the article includes some screen caps, it's mostly a high level overview. It does go through some of the usage and features, and even includes some use cases. While a good intro, it doesn't even include links to the package.
BottomLine: High level intro to AI Kubernetes tool called K8GPT
==
URL reference: https://fixyacloud.com/kubernetes/how-to-ssh-into-kubernetes-pod
DateReviewed: 2024-01-21
Description: Okay, so I'll be pedantic - this isn't "ssh"ing, but rather getting a CLI/shell on a container. They do walk through displaying pods, identifying which one you want to access, getting the shell open and coming back to the node. They also explain how to copy files around. Short and sweet, and done well.
BottomLine: Quick piece explaining how to get a CLI shell on a pod in Kubernetes
==
URL reference: https://github.com/diggerhq/digger
DateReviewed: 2024-01-22
Description: Digger is an alternative to the Terraform ecosystem for CI, and we're going to do a short tour of the repo. Basically it's got two parts - the CLI part that actually does the CI bits with your Terraform, and a minimal Orchestration backend that watches for things like PR comments to fire off the process. They have docs for GCP and AWS, and just recently released an official Docker image. It's a neat tool if your using Terraform and don't want to buy or run a bunch of other bits just to have the CI/CD function connections.
BottomLine: Neat CI tool which leverages Terraform in a simple way for builds
==
URL reference: https://tkachuk09.medium.com/kubernetes-hpa-based-on-events-in-google-calendar-2f3dcfb75bf2
DateReviewed: 2024-01-23
Description: We start with an org using K8s, but when scaling the new pods aren't coming up fast enough so existing pods get overwhelmed and crash, with this repeating over and over. So, they deceided to use a calendar entry since they know when loading occurs. This is a walk through, so they show us the Google calendar event fetching code, and then the K8s cron job to tie things in. They show how it figures things out, scales up by 10, and then when the "event" is over, scales back down by 10. Upfront they admit this is a hack, but it's kind of neat -- and it has some other uses that I can think of, like adding extra monitoring or doing a backup or testing at specific times. Well done and well documented.
BottomLine: Interesting approach to a scaling issue with Kubernetes -- a Google calendar scaling trigger walkthrough
==
URL reference: https://blog.payara.fish/you-might-not-need-kuberenetes.-or-containers
DateReviewed: 2024-01-24
Description: We start with the possibility that K8s is a "new shiny thing", and not the solution to every problem -- interesting. The discussion is going to be if Kubernetes really provides value, and if so, where. The first case is small shops, where it's argued that managing K8s takes up more time then devs need. They give an example of WHOA BIG FELLA their own platform, which allows things like Java EE to be deployed. Now, I'm not against ads, but most articles at least mention they are going to talk about their platform, and honestly I was caught by surprise. Their platform might be fine, and they laud it -- if it fits your use case, give it a shot -- but it would have been more compelling to lay out how a generic platform performs better than K8s. The second half of this is all about their hosted offering, and it feels like a big ad. Now, you might not need Kubernetes or containers, sure, but this article does a bad job of doing the convincing. They started, and pivoted too soon, in my opinion.
BottomLine: Good premise but poor arguments means it doesn't convice us we don't need Kubernetes
==
URL reference: https://therecord.media/google-kubernetes-engine-security-loophole-access-permissions
DateReviewed: 2024-01-25
Description: This one is a news article, on a Google Kubernetes weakness. Basically the issue is in spinning up a GKE Kubernetes cluster, if people aren't aware the default permissions leave their cluster open to anyone with a Google account to be able to do some actions on their cluster. It was found by a group called Orca security. Google worked with Orca to identify and reach out to affected customers and explain the issue and how to tighten security. Good coverage of all the points here.
BottomLine: News item on GKE Kubernetes weakness with overly permissive permissions
==
URL reference: https://medium.com/@teva15/services-and-networking-in-kubernetes-ed23509ee4b4
DateReviewed: 2024-01-26
Description: This article will focus on Kubernetes services and networking. We start with a diagram, cool! Next up is the definition of a service, and examples of typical services in K8s. They have some good diagrams showing how an externally accessible port is mapped through a service to a pod, with explanitory text in the article. They even have YAML snippets to show how to do it. They then go through different scenarios in diagrams to illustrate. Now it says this is a tutorial, but it isn't a straight walk through, but more of illustrated examples. For instance, they talk about Redis in diagrams, but not in the text. They talk about frontend in the text, but don't have a diagram. It's still useful and illustrates differences, but it would have been nice to connect all the dots.
BottomLine: Decent intro to services and networking in Kubernetes
==
URL reference: https://semaphoreci.com/blog/kubernetes-ssl-tls
DateReviewed: 2024-01-27
Description: We start with the assertion that security is important, but then use an analogy of a public mail system where anyone can read contents - but postal systems aren't secure really. They don't actually explain SSL/TLS, but hand wave at it a bit, to focus on how Kubernetes does this. It's going to be a walk through, so there are prereqs, including Helm. They do a bit more SSL background, and we see a YAML file to deploy a front end app. Next, we set up a namespace to handle certs, add a repo and updated the Helm repos. They then install the certmanager. They explain the nuance between a ClusterIssuer and an Issuer resource, and explain they will be setting up a Let's Encrypt plugin. Another YAML and we have our cert bits ready. They then use the Ambassador gateway with a few external YAML scripts to set up external access for our front end. More YAML to create a load balancer that opens 80 and 443 to the outside, and then apply the YAML. One more bit of YAML for Ingress, and bam, we can serve a site on 80. To get it working securely, we craft a Cert request YAML and apply it, and then K8s spins up a pod to grab a cert for us. We need to add some YAML so the cert verification works, and of course apply it. To actually use the cert, we now need a bit more YAML on another Ingress declaration referencing the TLS bits and applying. Now, hitting the SSL version of the site works. Whew! So, it's a decent walkthrough and gives a good understading of what is needed to make everything work.
BottomLine: Full walkthorough on getting SSL/TLS working on Kubernetes
==
URL reference: https://dev.to/neeraj1997dev/kubernetes-cluster-step-by-step-5940
DateReviewed: 2024-01-28
Description: We start with some formal definitions, which is always the best way to slide into a challenging topic, not. It's going to be step by step, so let's get started. Step one is "install compatible OS", which .. okay. Step two is "install Docker (or compatible container runtime). Step 3 is install kubeadm, kubelet and kubectl. I'm going to stop here -- it does go on for more steps, and it also does have the commands you have to do to install the bits, but this is all very handwavy. Like, it theoretically would work, but they don't show any output so I'm guessing they are culling this from another guide. So, works in theory, but I might actually put this one to the test.
BottomLine: Says it is a step by step guide to getting Kubernetes to run, but seems fairly loose.
==
URL reference: https://ashishnoob.medium.com/persisting-state-in-kubernetes-configuring-persistent-storage-for-stateful-workloads-a2a7566db7cd
DateReviewed: 2024-01-29
Description: This article is about persistent storage, and how to make that happen in a Kubernetes enviroment. It's a hands on, so we get a pre-req list upfront. Next we talk about Persistent Volumes (PVs), which is how Kubernetes allows a pod to keep something long term. The article shows the YAML and the command to allocate/apply it, which puts the volume out there in the cluster. But, for a pod to use it, it needs to connect to the volume -- enter the Persistent Volume Claim or PVC. Again we are shown YAML and the command to apply. Finally, we see how to spin up a pod with such a PVC attached, with YAML and apply command. They then do an example config, for a MySQL db, and show how that is in YAML and applied command. Short but very helpful walkthrough.
BottomLine: Walkthrough of using persistent storage with Kubernetes
==
URL reference: https://medium.com/thermokline/declarative-linux-nixos-the-server-management-solution-you-have-been-waiting-for-75eb742cfa31
DateReviewed: 2024-01-30
Description: We start talking about how to handle bare metal servers. They walk us through the typical process, which starts with a PXE boot server, an OS configure script, installing the OS then installing the app env. They are advocating using NixOS to handle this, and let's see their approach. Config is all contained in files, and they claim that installing can be standardized and done in an idempotent way. One trick I love is "updating the config and switching to it", which has been done for years on network hardware. They also claim that NixOS allows you to create a shell env with things like debugging tools, but that is then cleared when exiting the shell -- very neat. I actually want to give this a go now, it's a very compelling piece.
BottomLine: Great take on why NixOS could be a good fit for deploying to a bare-metal system or lab
==
URL reference: https://snyk.io/blog/leaky-vessels-docker-runc-container-breakout-vulnerabilities/
DateReviewed: 2024-01-31
Description: This is a blog article about the discovery of a container/Kubernetes vulnerability dubbed Leaky Vessels, which can result in a container escape. The gist is that in running or building a crafted image, the "runc" command can be exploited to allow access to the underlying host OS, giving you full control of the node running the containers. The vulnerability is patched in v 1.1.12 of runc relased on 2024-01-31. To help identify and detect crafted images, Snyk has built a runtime detector to surface images which exploit the issue, which can be used prior to patching to mitigate issues. They also released a static scan tool which identifies build/run files which could be vulnerable to the issue. The team that found this said they did check popular image repos and could not find any current exploits in the wild, but note this isn't an exhaustive search. All cloud providers and both Docker and containerd have released updates to the latest version. While this is a serious vulnerability, quick co-operation seems to have blunted the effects.
BottomLine: Container and Kubernetes vulnerability in runc allows container escape in image build processes
==
URL reference: https://trickest.com/blog/enhancing-kubernetes-security/
DateReviewed: 2024-01-31
Description: Okay, so we start thick here, with 3 recent high profile Kubernetes security breaches, which seem to show K8s is not great security wise. We pivot from there to a quick overview of K8s(?), then move on to why security is important. There are 5 main points, all followed by a paragraph explaining them. We then have OWASP K8s top 10, with our product pitch on the heels - Trickest can enumerate K8s. We get some neat diagrams and hand wavy text, and then we're into securing K8s. There are 7 main areas, again with a para to follow up. Overall not terrible, but VERY high level and not very cohesive.
BottomLine: Okay high level into to Kubernetes security -- but there are better out there
==