Archive

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 😁)! ...

Following up on the recent blog post series about Continuous Delivery to AKS with Azure DevOps Environments: 🐱 Part 1 🐱 Part 2 I would like to share a simple but really useful way to re-use the same Azure DevOps Environment in multiple deployment stages across multiple pipelines. Normally if you want to deploy multiple applications to the same AKS cluster, you would specify a target Azure DevOps Environment by writing it's name in environment property of deployment stage of every application: ...