Something that I love is to be able to troubleshoot fast (or at least have the right tooling for it). Working in a Kubernetes environment, I often find myself needing to get pods environment variables and secrets either for debugging purposes or auditing. I wanted something that would give me everything I need fast and at a glance in my terminal.
In this blog post I’ll share the little script I created to achieve this and how to add it to your shell as a function.
If you are working in an Azure environment and you are using Azure Availability Tests you might run into the following Health Advisory event:
On 31 October 2024, in alignment with the Azure wide legacy TLS deprecation, TLS 1.0/1.1 protocol versions and the below listed TLS 1.2/1.3 legacy Cipher suites and > Elliptical curves will be retired for Application Insights availability tests.
For a list of deprecated versions and remaining supported versions have a look over the official documentation here.
Recently a new vulnerability in OpenSSH has been identified and the first question that popped into my mind was: How do I make sure my nodes are not affected by _this vulnerability?
In this blog post, I wanted to go over what the vulnerability is, how it can be exploited, explain how you can check if your Azure Kubernetes Service (AKS) is vulnerable to CVE-2024-6387 and what you can do about it, including different options for upgrading the VMSS image and how to choose between them.
This blog post will be a quick one focusing on troubleshooting a less clear error, ‘Cannot delete entity, must remove tokens from principal first’, that Terraform can throw when you try to delete IAM users from AWS.
Let’s assume that in your Terraform configuration, you manage IAM users and you want to delete one of them. You’d think that by simply removing the Terraform code and then running terraform apply it will delete the users. Which was my case. But then as soon as I ran the command to destroy the resource I ran into an issue:
Recently, I had to enable WAF on our Azure Application Gateway. Because of our infrastructure setup, I wanted to have all the rules from OWASP 3.2 enabled, but I needed to be able to exclude some of our (valid) requests from being blocked as well. To achieve this, I could either try to configure the WAF Config section on our Gateway or create a WAF policy.
Given that it was not entirely clear how you can use proper exclusions and filters based on what you need, I decided to write this post to explain the differences I found between the two and how you can use them.
A CNCF project, the Distributed Application Runtime (Dapr) provides APIs that simplify microservice connectivity. Whether your communication pattern is a service-to-service invocation or pub/sub messaging, Dapr helps you write resilient and secured microservices. Essentially, it provides a new way to build microservices by using the reusable blocks implemented as sidecars.
While Dapr is great as it is language agnostic and it solves some challenges that come with microservices and distributed systems, such as message broker integration, encryption etc, troubleshooting Dapr issues can be quite challenging. Dapr logs, especially the error messages, can be quite generic and sometimes do not provide enough information for you to understand what is going on.
Currently, there is no option for adding a Group as an Owner to a Service Principal or Azure AD Application.
If you try you will most likely run into the following error:
unexpected status 400 with OData error: Request_BadRequest: The reference target â 'Group_0000000-0000-000000-000000' of type 'Group' is invalid for the 'owners' reference. This is a quick post on how you can add members of an Az AD Group as Owners of a Service Principal or Azure AD Application. This is useful if you want to give your team members access to the Service Principal or Azure AD Application without giving them access to the Azure Subscription.
The other day I was making changes to my helm charts and, after deploying my application, I noticed that one of my pods was stuck in a CreateContainerConfigError state. This is a pretty tricky error because it doesn’t give you any details on what the underlying issue could be.
What is the CreateContainerConfigError? # To understand this, let’s look at what happens at deployment time to give you an idea of the flow and what could go wrong at each step.
In today’s world, security is a top priority for any organization or at least it should be. With the rise of cloud computing, the number of security threats has increased exponentially.
So how do we keep up? Where do we start?
Microsoft has created a set of security benchmarks to give users a starting point for setting up their security configurations. The Microsoft cloud security benchmark (MCSB) is the successor of Azure Security Benchmark (ASB), which was rebranded in October 2022 (Currently in public preview).
When I started migrating to Kubernetes (K8s) I discovered that I can use Terraform for managing not only the infrastructure, but also I could define the K8s objects in it, but I also could use Helm to handle that. But what would be a good way to handle this?
In this post we will cover Terraform and Helm for managing Kubernetes clusters with some code snippets and an idea on how you can use them together to get you started.
