One day I was going through Azure Policies for Kubernetes and suddenly saw an alert related to the following policy for one of the AKS clusters: Kubernetes clusters should not grant CAP_SYS_ADMIN security capabilities. What this basically means is that you shouldn’t have any accounts in your cluster that have been assigned a ClusterRole or Role with CAP_SYS_ADMIN capabilities. CAP_SYS_ADMIN is a capability that is available in Linux. It provides a very privileged level of permissions that allows an account that has this capability to perform a range of system administration operations which can potentially be harmful and damaging for the whole system. You can read more about this capability here: capabilities(7) — Linux manual page. ...

If you've worked with Kubernetes for a while you should have seen that version lifecycle that Kubernetes has is pretty aggressive. Kubernetes is being actively developed which means that new releases come out pretty frequently - and all of us who are using Kubernetes, be it a managed or a self-hosted distribution, must adapt and adjust. If not, we may risk running our workloads on unsupported version of Kubernetes with lacking security and functionality fixes. In addition, when the time comes to upgrade there's a big risk that the change gap will be too large from the Kubernetes version you're running and the one you want to upgrade to - this normally ends up in a complicated and unstable upgrade process which I wouldn't recommend to anyone, especially in a production environment…😑 ...

With release of .NET and .NET Core one significant change you may have noticed is the new version support lifecycle. .NET Framework LTS (long-time support) versions are normally supported for 5+ years by Microsoft but support lifecycle for .NET and .NET Core LTS versions has decreased to 3 years. The main reasons for the shorter support lifecycle are the overall faster technology evolvement, but also more active framework development which requires frequent releases both from the functional and security perspective. ...

There is one scary property in .NET which, if misused or forgotten, can make your security champions tremble at night…🙀🙀🙀 As scary as it sounds, the risk of forgetting or misusing the property is pretty serious and I've seen it multiple times sneaking into the source code as part of the pull request. And I keep seeing it still. Therefore this tech tip gets to see the world.☀️ The property I'm talking about is ServicePointManager.ServerCertificateValidationCallback that is part of a System.Net library. This property can be used for custom certificate validation in case you're using a non-trusted certificate authority. One of the scenarios when you can end up using this property is when you're developing and testing new functionality and you're using a self-signed TLS certificate on the server instead of production-level certificates. If this property is not set and you're using a non-trusted certificate, you may get errors like: The underlying connection was closed: Could not establish trust relationship for the SSL/TLS secure channel. ...

In some cases you may have an Microsoft Entra ID tenant that doesn’t have an active subscription connected to it but you would nevertheless want to log in to it from a command line for instance, with Azure CLI. You may want to perform actions like creating a Microsoft Entra ID Application for example. In this case you need to be cautious about the login command you’re running so that you don’t waste a lot of time on debugging an error you could have avoided in the first place (like someone did 😁)! ...