URL reference: https://magnintel.com.au/cloud-security-best-practices/
DateReviewed: 2024-02-01
Description: This piece positions itself as a Cloud sec best practices for small biz; I have some thoughts on this, but let's dig into the article first. They say they want to dive into risks, and give that all of one sentence. So on to best practices! They have 10 best practices, and use a formula of "what it is, how it helps, implementation tips" on all practices. Covered includes Data encryption, access controls & identity mgmt, security audits, MFA, Incident response planning, data backups, vendor security assessment, employee training, secure config and finally legal and compliance regulations. They then list 5 ways using best practices saves money. Now, the covered topics are decent and fine intros, and the saving money is nice. My problem with the piece is that it is aimed at small biz, and where would small biz have money for audits and incident response? This feels more aimed at mid-sized biz, or maybe in AU small biz is bigger?
BottomLine: Okay intro but weirdly aimed at small biz for Cloud security
==
URL reference: https://medium.com/@vishy.nitj/understanding-mutual-ssl-authentication-85efb2b050f4
DateReviewed: 2024-02-02
Description: So here, we're looking into mutual auth for SSL, or mTLS. Now, the setup is a bit weird, as it refers to a certain website, but okay. They then go on to show you the OpenSSL commands, without really explaining what OpenSSL is or what they do (they create keys, then a cert request, then sign the certs). They then use the certs to create Kubernetes secrets. We then get YAML to deploy the certs, which is cool, and to access them. Finally we do a test with Curl to validate the keys. While this is scriptable, I did just review a mTLS setup that does the Cert process for you. But this is a good local test alternative.
BottomLine: Shows you how to set up mTLS for Kubernetes on the CLI
==
URL reference: https://medium.com/@angelomarchaidez/docker-flask-kubernetes-building-a-lottery-application-with-python-8d38af40a3d4
DateReviewed: 2024-02-03
Description: This is about building a lotto app with Flask, and a way to work with containers. It's a simple lotto guesser app, that shows you the likelyhood of your numbers winning. They go through the UI, and explain how things will work. Then, they give the Python code which will run the backend, and then explain what it does. They then show us the html templates for data entry and results, which Python will use on the web side. Now that it works, we're going to Dockerize it so we can create a container out of it. We grab a Python base image, make some tweaks and build an image of the Flask app. We then go through the process to push to Docker hub. Now they go through the process of using this image, in this case by a YAML file to create a Kubernetes deployment, and then goes through the K8s CLI command to get it running.
BottomLine: A good basic walk through of deploying a Python app to a container
==
URL reference: https://medium.com/@SaiDevaPro/exploring-advanced-concepts-in-kubernetes-unlocking-its-deepest-potential-d92b79094594
DateReviewed: 2024-02-04
Description: Apparently, we're going to wield K8s to it's fullest potential, so let's go. We start with CRDs and Operators, and they explain for a para each what they are. Moving on we look at Advanced networking like service mesh, which K8s enables but they don't actually explain. Next up is Persistent storage, where they talk about various mechanisms. There are three more topics covered, but each of them is about a paragraph long. They include Resource mgmt and autoscaling, Observability and monitoring, and Security and compliance. All are great topics, but I'd say this piece fails to live up to it's potential, with a scratching the surface coverage of all topics.
BottomLine: Good topic list but poor in-depth coverage, this piece disappoints
==
URL reference: https://medium.com/@seifeddinerajhi/most-common-mistakes-to-avoid-when-using-kubernetes-anti-patterns-%EF%B8%8F-f4d37586528d
DateReviewed: 2024-02-05
Description: We start with Kubernetes is powerful, but it's easy to make a config mistake. So this article will work to help you avoid them! So, there are ELEVEN areas of concern they tackle, and all of them are fairly good. And they even come with a bunch of paragraphs going through each topic, with diagrams where approporiate. Just a few of the areas they cover include resource limits, health ckechs, privs of containers. and overuse of LoadBalancer. Overall, a well done piece.
BottomLine: Very good piece detailing common config mistakes in Kubernetes and how to avoid them
==
URL reference: https://securityboulevard.com/2024/02/kubernetes-security-best-practices-definitive-guide-for-security-professionals/
DateReviewed: 2024-02-06
Description: Kubernetes uptake increase, it's security becomes more critical, so in this article we'll look at K8s security practices. We start with a short overview of K8s, and then get to what is Kubernetes security. So, K8s security isn't only the cluster, but also the infrastructure that it is deployed on. They argue that one bad container can be equal to an entire compromise of the cluster, which is a bit of scare mongering in my opinion. We then jump into a chat about the four C's, which is decent, and then they go into detail, explaining what thing are and how they relate to each other. While still high level, they do dig down into concepts and try to build understanding. There is one new concept to these best practices pieces -- the idea of shifting left, or doing security earlier in the dev process. It's a long and actually good intro, despite a bit of fear mongering early on. I'd say it's a good intro look at Kubernetes security.
BottomLine: Solid high-level Kuberentes security intro, which does try to go deeper into understanding the various areas
==
URL reference: https://medium.com/@kavishkafernando/exploring-the-kubernetes-architecture-a-foundation-for-modern-application-deployment-f2c0f15d661e
DateReviewed: 2024-02-07
Description: We start of by talking about what Kubernetes provides, and this article will approach things from a development perspective. We start with K8s arch, along with a decent diagram to help a dev understand where we are. We go through the components on the "master node", which is actually the control or backplane of K8s. There are 5 they go through, with a short paragraph laying out what they do. They then tour the Worker nodes, explaining Kubelet, Kube-proxy and the container runtime. They do brief runthroughs of pods and K8s networking, and end up talking about persistent storage. A quick but decent dev overview.
BottomLine: A quick developer focused overview of what Kubernetes is and how it works
==
URL reference: https://dzone.com/articles/bridging-the-observability-gap-for-modern-cloud-ar
DateReviewed: 2024-02-08
Description: Cloud allows complexity, but with this comes fragility and opacity in observability areas. So the apparent answer to this is of course AI, which we'll check out in this article. They look at using AI for code specifically, and found it was less complex and had better style adherence, wasn't worse security wise but had less test coverage. They then start to talk about AI observability, but don't rely dive into details much. A bit of handwave is given to ML and models, but not how they are used or what they are doing. Finally we get to something interesting -- being able to monitor data "freshness, volume and lineage" -- which does sound interesting. A few more paragraphs and they wrap up. So, it's a lot of words to not say too much. It's VERY high level, but while introducing tools it doesn't explain why you'd need them or really what they do. It doesn't do a compelling job of motivating you to even find out more.
BottomLine: No gaps are filled with this article -- not even worth a skim
==
URL reference: https://fixyacloud.com/kubernetes/how-to-configure-coredns-for-kubernetes
DateReviewed: 2024-02-09
Description: We start with a quick paragraph explaining that K8s is popular, and that DNS is a key glue to hold things together. In this article, we'll do a walk-through of installing CoreDNS, which offers service discovery and DNS based load balancing. They quickly explain that CoreDNS is an alternative to the built-in kube-dns and is more flexible, and then we're onto our prereqs. Next up is the actual start of our walk through, and each explains what needs to be done and then gives the CLI command to do it. First is installing CoreDNS. Next is verifying that it's running as expected. They now give us a YAML config file and we use this to actually configure the DNS. Our new config needs a restart, and we have to emit a command for this. And we want to verify that things are still running, so another command. We're thorough though, so we also do a lookup to make sure the DNS resolution is also working. Quite tight and fairly well done -- I'd have liked some output and maybe a diagram, but overall a very solid walkthrough.
BottomLine: Very good walkthrough of installing CoreDNS on Kubernetes
==
URL reference: https://contabo.com/blog/mastering-kubernetes/
DateReviewed: 2024-02-10
Description: Apparently a sequel to an older guide, this article will tell us how to really master Kubernetes. We start with configuring applications, and they go through Config Maps, Env variables and volumes for config files. This is done at a high level, but it gives a decent understanding of how things are done. Next is secret handling, and they go through best practices and explain how things work. We then move on to monitoring K8s, and they talk about both simple and more complex approaches, which should be tailored to your situation. They then have a decent section on troubleshooting, and tips and techniques you can try to track things down. We then move on to Security in K8s, and they cover RBAC here. We also dip into securing Pod comms, and this gets into Network security in K8s. We move on to K8s benefits (why isn't this in the basics?) and use cases, which are short and high level, but decent for a toe-dip. We conclude with a K8s cheat sheet. I'll say I'm a bit disappointed -- it's quite high level for a "mastery" document, but as a general overview it is very solid.
BottomLine: Good general overview of Kubernetes topics - but lacks deep dive to be a master
==
URL reference: https://www.valewood.org/topics/devops/learn/get-started/engineering/early-devops/
DateReviewed: 2024-02-11
Description: We start with some preamble that doesn't relate before scrolling down to the actual article, which promises an exciting career in DevOps. They do explain that DevOps is a team approach, and that there is lots to know. We have to know code, and they point to languages like Python and Ruby; then they explain we'll be using automation tools like Chef or Puppet. At this point, I tried to find a publish date, because no one is doing new projects with these tools now, as opposed to Ansible or Terraform. They do highlight skills and understanding, and keeping up to date in the community with things such as conferences. They talk a bit about practices, like Continuous Delivery or Site Reliability and how this helps build a strong culture. We also talk about Automated testing and IaC, and how they build on other practices. Unfortunately, in the end they try to build a roadmap but seem to get lost in the wilderness, and while they use a lot of good phrases, there isn't great advice on what to do.
BottomLine: DevOps jobs piece that starts strong and finishes weak
==
URL reference: https://fixyacloud.com/kubernetes/how-to-create-init-containers-in-kubernetes
DateReviewed: 2024-02-12
Description: We start with a brief overview of init containers, the startup scripts of the K8s world. This is a walk through, so let's go! First, we start by defining the init container in YAML, so they show us how to do it for both the init and the main container. They then explain what we should be doing in the init container - downloading dependencies, db setups, and configuring environment variables. We can run them in parallel or sequentially, depending on our needs. Finally, the give us a command to check the init container status. Now some examples - includes downloading a dependency and etting a env variable.
BottomLine: Decent walk through of init Containers for Kubernetes
==
URL reference: https://www.stb.id.au/blog/meet-kacti
DateReviewed: 2024-02-13
Description: This is about a security control in Kubernetes called Kacti, and is told by its author. So what kacti does is try to deploy known bad images or misconfigurations, and see if that succeeds. If it does, controls are not effective. It's a neat approach. Just to be clear, the test is performed against your admission controller and its policies -- and it should reject bad configs and images. Next we do a walkthrough. First you install the software, and then they show us the CLI for deploying a bad image. At first, the bad image is deployed, and kacti fails the controller; then they add checking for bad images and re-run, causing the controller to reject the image and pass the test. They give a bit more details along with a bit of what they'd like to come, as it's a new tool.
BottomLine: Interesting approach to security by testing your Kubernetes admission controllers
==
URL reference: https://securityboulevard.com/2024/02/exploiting-kubernetes-through-operator-injection/
DateReviewed: 2024-02-14
Description: We start with a short blurb on what controllers are and that they can be a bespoke attack surface. This article will take us through an attack on a controller. So, basically this is an input sanitation attack, but performed against a component that is used to deploy infrastructure. The article is a bit vague, but I believe what they are doing is exploiting a YAML property that allows you to put multiple YAML documents into one file, with a delimiter. Once the delimiter is hit, the payload is the deployment of another container which does what the attacker wants. It's a novel attack, and it points to the fact that you have to make sure the API components and extensions are written carefully and well validated.
BottomLine: Novel attack on a custom Kubernetes controller which allows an attacker to run their choice of container
==
URL reference: https://itnext.io/kubernetes-silent-pod-killer-104e7c8054d9
DateReviewed: 2024-02-15
Description: Are Kubernetes processes weirdly disappearing on you -- this is the premise of this piece, focused on OOMKiller. For those who don't know, this is caused by a K8s container running out of memory coupled with the fact pods generally run swapless and thus limited to the memory allocated. The article says you can see this in either an event or the pod-related YAML, but otherwise it isn't easy to notice. Ah, while the article doesn't say earlier, the issue here is that a _subprocess_ is getting killed which causes issues that are hard to see. So in K8s v1.28 on, there is a setting which you can set to kill the entire process tree if a single process is a candidate for an OOM kill. Unfortunately, the setting isn't configurable currently, so all 1.28 clusters will get this new beahviour. Finally they do talk about ways to detect OOMKill events pre 1.28, so you can be more aware of them.
BottomLine: Good walkthrough of strange issues that can be caused by OOMKill on Kubernetes
==
URL reference: https://medium.com/google-cloud/openziti-zrok-and-kubezt-a-triad-to-make-security-easy-1f2d905b02b9
DateReviewed: 2024-02-16
Description: We start .. weirdly, with a ref to the ex of the author? No real upfront motivation other than these are "good" security tools. We then jump right into OpenZiti, where we go through some of the things it does but not the why. They then do a walk through, so from that it looks like its an auth piece for services and comms. It shows a few snips with comments, but there is no discussion. On to zrok, a gateway app for safe access, I think for allowing connections and file access through their service? Again, more snips showing how to use it, and it feels like it creates a secure tunnel. Finally we move to Kubeziti, which they say helps integrate the other apps but they use to do an image scan in their first snip? Oh, it's security policy enforcement, with the scans being one prong of that. Now, they ramble on a bit here, but honestly the earlier bits are too odd to save the piece -- the tools may be interesting, but the piece does not do a great job to bring understanding to them.
BottomLine: Confused article on seemingly good tools which is a skip
==
URL reference: https://securityboulevard.com/2024/02/how-to-monitor-kubernetes-audit-logs/
DateReviewed: 2024-02-17
Description: We start with K8s is powerful, but can be tough to ensure it's secure. So this article's focus will be on how to build an audit and logging system to do this. After a short prelude, we go through a few paras each on what is K8s and containers -- which seems odd if you are worried about auditing K8s, but maybe this is for biz people? Next up is the importance of logs in K8s, explaining that logs contain detailed records of actions and events that Kubernetes performs. We then go through an acronym soup of things audits can "help with". Next is a section on how audit logs help meet requirements -- the good stuff. It's all high level, and feels cut and paste - there is no K8s specific bits here. We then go through some of the common log event types, where again at a high level, we're told what is captured. They handwave a bit at K8s Architecture, explaining the master and worker nodes, and even include a diagram and a short description. Oddly, we pivot from high level to YAML here, with an actual policy. Oh, and a bit of a pitch to use a specific monitoring tool (LogRhythm). They explain how the info flows through the log and monitor system -- first is RequestReceived, then ResponseStarted, and next ResponseComplete, where clients request, the server start and then sends the requested info. If there is something unexpected, there is a fourth event, Panic, which indicates the request was unusually aborted. We then do a bit more low-level config and we are shown a dashboard. Okay, wow. While this piece has good parts, it's all over the place. It's not sure if the audience is a biz guy or tech; newbie to K8s or experienced; or where they are on the security spectrum. I feel like the different parts were written by different people, and stitched together by someone who didn't read or at least understand the whole thing.
BottomLine: Good premise and decent parts but ultimately all over the place -- misses on delivering the title promise
==
URL reference: https://www.tripwire.com/state-of-security/security-risks-kubernetes-helm-charts-and-what-do-about-them
DateReviewed: 2024-02-18
Description: We start with K8s being the leading orchestration platform, but, dun dun dun .. security issues, and this time with Helm. Helm charts are one way to manage orchestration, and it has become somewhat of a standard -- and this aricle will tackle security concerns around them. They start by identifying four areas of concern -- Insecure defaults, dependencies, access control issues and embedded secrets. They point out sometimes charts are crafted for ease of use as opposed to security, which is likely true. They identify a number of issues, most of which are ease-of-use considerations, which might be more worrisome in a production environment. They have some suggested mitigations, including dependency checks (and using a vuln scanner), using access control (in the form of RBAC), validated inputs to charts, using secrets management and auditing and keeping Helm charts up to date. Honestly a good review of issues and decent mitigations.
BottomLine: Exposes potential issues with Helm charts used on Kubernetes and gives some solid mitigation advice
==
URL reference: https://blog.realkinetic.com/cloud-without-kubernetes-d0487a4ab345
DateReviewed: 2024-02-19
Description: Kubernetes is the most popular way to do cloud, but this piece asks should it be? They take a case-study where a large company wanted to go 100% serverless -- no VMs, no K8s. It seems they were able to do it. Ah -- the rub here though is that they are using container-based code and doing some modifications to use Google's Cloud Run. They talk a bit about how they are actually running things, using a specific interface that works both in K8s and serverless. They address cost issues, arguing that due to spikes and troughs most businesses can run with less costs in serverless. The author then proposes something interesting -- that most "normal" biz just want to run code, like PaaS, not run the infrastructure. So, the bottom line here is to see if Google's Cloud Run might work for you.
BottomLine: Interesting perspective piece showing ways to run apps without Kubernetes
==
URL reference: https://engineering.01cloud.com/2024/02/20/does-containerization-affect-the-performance-of-databases/
DateReviewed: 2024-02-20
Description: We start with a straightforward approach -- Databases are being deployed more in containers -- are there drawbacks for these workloads? We dive in with a bit of background on K8s and what advantages it has. We then go through some container terminology and various types of containers, along with a nifty table which outlines them. We then dig into the issues that databases face in a container, like performance needs (CPU, memory and disk IO access) and the need for disk persistence. It then does a deep dive into various areas to see where containers seem worse than bare-metal servers. Overall, it seems containers are more competitive in almost all areas than one might think. We end with a walkthrough of a list of actual issues that do affect containers which might strike a DB server a bit harder. Overall, a good thought piece.
BottomLine: Walk through of performance of a database on various container platforms including Kubernetes
==
URL reference: https://medium.com/@preciousdipe/understanding-kubernetes-architecture-from-nodes-focus-6cd487fa49dd
DateReviewed: 2024-02-21
Description: We start with Kubernetes being popular, and explaining how it solved problems devs had in the past. We dive in with them citing ease in managing containers as pods. We touch on auto-healing and mention auto-scaling, which help in stability and load. As opposed to running a single Docker instance, there is a lot of flexibility on where and how K8s clusters run. A couple of diagrams and a terminology walkthrough are up next. And thats .... it? There is a couple links at the end, and while it has some good intro bits, I wouldn't say this is a piece where you understand the K8s architecture from.
BottomLine: Good Kubernetes intro but not a great architecture piece
==
URL reference: https://www.tigera.io/learn/guides/kubernetes-security/kubernetes-security-context/
DateReviewed: 2024-02-22
Description: We start by answering what K8s security context is at a high level, which is a way to configure security setting on the Kubernetes cluster. They give a bit of detail, and then we have a table of contents. There are two types of contexts - internal, which is through a pod's YAML file, and external, generally at the node level by things like SELinux. They then walk through RBAC and Pod security policies, and explain how they differ from the K8s security context. We then go through context setting, which include a paragraph or two explaining what they are. There are five options, three settings and two flags. We then to a tutorial walk through, with YAML files and CLI commands. Finally they explain the shortcomings and challenges of using the K8s security contexts. Overall, a good and interesting piece.
BottomLine: Good interesting piece about Kubernetes Security Contexts
==
URL reference: https://optimizedbyotto.com/post/linux-containers-docker/
DateReviewed: 2024-02-23
Description: Docker has popularized containers, but apparently is on the decline, so this article is going to compare Docker and it's newer alternatives. We start by diving into Docker's origins and early path, and how it was very helpful. The author also points out how Docker expanded the reach of Linux through containers. They handwave reasons for the decline and note the founder no longer works with the Docker company. They then dive into what is a Docker container, ans start with how one is built. They take us through the Dockerfile and docker build, and explain what happens is much like a shell script executing. The result is an overlayed filesystem and an entry point -- the thing the container should run. We next dig into the artifact of the build - the Docker image which can be used to run the application. They show how you can use ordinary Unix tools such as tar to view a Docker image by using the export command. They then go over some options, like creating an OCI container. Now we tackle actually using the image -- running the container. We're presented with a complex diagram that shows many parts of the container landscape, and various tools that do various parts. They run through various "runc" implementations, which is what the container image is executed by. They talk a bit about podman, which is the Docker alternative stack by RedHat. They then talk about LXC and LXD, which are container runtimes that have a slightly different philosophy then Docker. Overall a good tour.
BottomLine: Very good tour of Docker and the alternatives for building containers
==
URL reference: https://cloudresumechallenge.dev/docs/extensions/kubernetes-challenge/
DateReviewed: 2024-02-24
Description: Unlike most articles I review, this is actually a learning challenge you can add to your resume when complete. The background is deploying an e-commerce website, where you want availability, scalability and consistency. They list some pre-reqs, and step one is a (sponsored?) course in K8s, which you can skip if you understand K8s well enough. They want you to containerize, run K8s on a public cloud, deploy to your public K8s, expose your website ... you get the picture. There are 13 steps and 3 extra credit bits, and they provide suggestions and instructions on things you should be doing throughout.
BottomLine: A great way to test your Kubernetes knowledge and skill in real life
==
URL reference: https://thenewstack.io/the-top-5-kubernetes-security-mistakes-youre-probably-making/
DateReviewed: 2024-02-25
Description: We start with Kubernetes is a different security animal, but it has other advantages. This article will focus on the five most likely mistakes. Number one is alerts with context, which is fair. Next up is config mistakes, and then lack of microsegmentation. Rounding out the top five are lack of continuous monitoring and insider threats. Each mistake is followed with a paragraph or three of explaination and illustration, making it a decent piece. They then go on a bit about eBPF and how it's helpful, with a paragraph for each mistake and how eBPF helps reduce or eliminate the impact. I will note that none of these identified threats are cloud or Kubernetes specific -- all of these can happen in a before-times on-prem env. But the piece is well done and the threats are there, even if they don't make K8s a different animal.
BottomLine: Good walk through of 5 Kubernetes mistakes with security implications
==
URL reference: https://loft.sh/blog/kubernetes-manifests-everything-you-need-to-know/
DateReviewed: 2024-02-26
Description: Okay, so honestly I didn't think this would be anything but fluff, but we start with a sober approach to K8s through a DevOps lens, and it explains that manifests (YAML) are the way to interact with a Kubernetes enviornment. They then dive in to explain what manifests are, which are JSON or YAML files that give control what K8s does. We even talk a bit about declarative programming. Next we dive right in to writing a manifest; first, we need to have a K8s install of some sort with kubectl we have access to. We start with a pod manifest, and they walk us through some of the bits which describe how things should get set up. Then we actually apply the manifest to create the pod resource, and they explain the CLI we have to emit to get that to happen. They walk through verifying ad interacting with the pod, which means grabbing the logs and running a shell. They even go through basic debugging a pod which is having trouble starting. They explain labels and selectors, resource limits and requests, and env vars and config maps. Each comes with a YAML snippet and at least a couple paragraphs of explaination. They even introduce some manifest best practices. A very good intoductory piece.
BottomLine: Solid intro to Kubernetes configuration with manifests in YAML
==
URL reference: https://mkdev.me/posts/helm-templates-and-values-make-re-usable-helm-charts
DateReviewed: 2024-02-27
Description: Our article is part of a series on Helm charts. In this episode, we're going to learn about reusablility through templates. We start by explaining what a general template is, and then how it applies in programming and Helm. We then dive into how to set up template files in Helm. The explain how to nail down a part we want to vary, and then how to generate the result file with the right CLI command. They then show how to use variable files to supply the values to be plugged in, again with CLI commands as appropriate. They even show how to do a simple conditional, depending if we deploy to dev or prod. This is a great intro to this snippet of Helm, and it has a video version too. My only complaint is that the article has a very thin column, but just my personal preference there.
BottomLine: Good intro to Helm templates for Kubernetes
==
URL reference: https://medium.com/statuspal/best-programming-languages-for-devops-in-2024-with-examples-0d3ca1f81851
DateReviewed: 2024-02-28
Description: We start with Site reliability eng maturing, so choice of programming lang is very critical. Quick sidebar - programming langs are very much an opinion-based thing, so I'm curious how they approach this. So we'll be tackling and comparing and surfacing the "most preferred" langs in SRE land. So, they do have some criteria, including Monitoring/alerting, Cloud admin, DevOps platform tooling, CI/CD, and finally Infra provision and Config management. We then examine a few languages, including Python, Bash, Powershell, GO, Rust and Cue. (Cue?) Again sidebar - from this list, they are looking at the deployment and managemnt here, not the genesis of an app, which should have been better stated upfront. For each lang, they have an overview, strengths and use cases, and a snippet. We get coverage like this until we get to Cue. Apparenly Cue is an open source data-validation language, which helps with config and validation. We also have a snip, which has no comments and looks like JSON. It's clear the authors think Cue is a strong contender, but they make a weak case for it. To conclude they do circle back to the strength of each of the langs without declaring an outright winner. I think the author should have declared their leader, and I think they could have done a better job if they think that should have been Cue, which honestly I'd never heard mentioned before this article.
BottomLine: Okay early piece for tooling languages which can manage deployments and resources in DevOps and Kubernetes
==
URL reference: https://praneethreddybilakanti.medium.com/1-5-demystifying-kubernetes-annotations-25f32e14d98c
DateReviewed: 2024-02-29
Description: We start with some waffle about adding extra info with annotations. Basically I think they are freeform metadata comments to convey special info to future people looking for it. They then jump in, explaining what they are (key/value pairs) and where you can use them - K8s objects like pods, services etc. They then give some use cases, like config info, build vers or timestamps type info, pointers to other info like monitors or analytics, contact info and much more. We then have some examples which are YAML snips, to demonstrate the use of annotations. They even have good best practices around using annotations. A great intro and explainer on what annotations are and how to use them.
BottomLine: Intro on starting to use Annotations in Kubernetes
==
URL reference: https://securityboulevard.com/2024/02/k8s-benchmark-report-are-organizations-meeting-nsa-hardening-checks/
DateReviewed: 2024-02-29
Description: The NSA published guidance about hardening Kubernetes cluster, and our article here looks at a report which sees what people have done about that. A note is that the report is from a tool vendor, so their may be some bias there. Diving in, they do say that on a Linux level, often apps have more privileges then they need. They also find that less than half of orgs have a Network policy, and those that don't are likely permitting traffic they might not want to. We go on a little sidebar about leaked configs, but the handwavy point is that loose perms can result in compromises and disclosures you don't intend.
BottomLine: Adoption of NSA hardening is lagging and this points out where and some options to close the gap
==