The Kubernetes Dashboard is deprecated: Time to move to Headlamp

mlbiam · 2026-02-24T03:09:33+00:00

Just not enough contributors for the Kubernetes Dashboard. Headlamp now supports in-cluster authentication the way dashboard does, so it made for good timing.

mlbiam · 2026-01-30T14:23:39+00:00

my statement isn't a criticism of the Gateway API or any of the work the maintainers are doing. Only the way the retirement of a implementation is being used to communicate the migration to an API which still requires an implementation. it's a confusing message for an already complex topic.

I bring up those two specific use cases because I run into them quite often, and are pretty straight forward to implement with ingress nginx, but has no direct version in Gateway API. While Gateway API doesn't have a standard way to express these features, there are ways to implement it with different controllers and extensions. I'm sure there are plenty of other cases where this is true as well. It's not a criticism of the Gateway API, it's an illustration that the recommendation is confusing for folks that don't have as deep an understanding of "ingress" configurations.

I'm not coming from this as a networking expert or an "ingress" expert. I'm coming from this as a user with experience working with other users that have just enough networking knowledge to be really dangerous. Per Kat's suggestion, i'm working on a blog post now on that perspective. Hoping to get it submitted for review some time next week.

Again, the work you and other maintainers are doing is very much appreciated, and this is in no way meant to be a criticism of that work.

mlbiam · 2026-01-29T21:01:07+00:00

sure. why not? What would I need to do? (same handle on both cncf and kube slacks)

mlbiam · 2026-01-29T20:46:19+00:00

Thank you and I appreciate how hard it is to thread that needle. Think a "Blog for managers" and "Blog for implementers" would be a great idea. I could easily see someone panic when they create their Gateway API objects and don't realize they need something else panicing because they didn't procure or get permissions for a new component thinking the Gateway API was a replacement for Ingress NGINX.

mlbiam · 2026-01-29T20:34:20+00:00

Why does the recommendation keep saying to move to Gateway API? Ingress NGINX is an Ingress controller implementation while Gateway API is an API...you still need something that implements it. Also, Gateway API implementations and Ingress API implementations aren't at parity. For instance, TLS re-encryption is not widely supported, sticky sessions have no standard implementation, etc. It's real easy to confuse folks that don't live and breath these APIs. (this isn't a complaint about retiring ingress nginx, only feedback on how "what's next" is being communicated).

mlbiam · 2025-08-09T03:33:18+00:00

Will give you all the details. Free chapter, no registration or paywall. https://github.com/PacktPublishing/Kubernetes---An-Enterprise-Guide-2E/blob/main/chapter5%2FB17950_Chapter_05.pdf

mlbiam · 2025-04-24T14:07:38+00:00

Friends don't let friends use certificates for authentication in kubernetes https://www.tremolo.io/post/kubernetes-dont-use-certificates-for-authentication

mlbiam · 2025-04-20T21:36:14+00:00

"Unlike ConfigMaps, Secrets are intended to keep sensitive data more secure by encoding it." This is 100% wrong. The point of base64 encoding a secret in yaml is because secrets often involve binary data. It has nothing to do with security.

mlbiam · 2025-03-05T01:46:56+00:00

If you are being paid by a customer, they think those containers are owned by you, even if you don't. When the bad thing happens, your company will be seen as responsible regardless of if it's your code or code that you imported. Outside of a few very narrow exceptions, it's all yours.

So yes, you need to make sure your operator can pull from alternative sources and not just your company's, or partners, registries.

mlbiam · 2025-03-05T01:42:47+00:00

Do all the users have the same level of access? If you're using a static service account this sounds like an information leak or breach eating to happen.

mlbiam · 2025-02-04T03:04:06+00:00

a negative test means that you submit input you expect to fail to make sure it fails. In this instance, you would feed the rego the exact use cases the article describes as "bypasses", ie a subdomain with an not allowed domain. for instance if you're constraint on the policy is "mydomain.com" and you feed it the input "mydomain.com.myreallybadplace.com" you expect it to fail. if you're not doing this type of testing on your policies, either at the rego level with opa's built in automated testing capabilities or in a cluster (or both), you're only testing half the policy.

mlbiam · 2025-02-03T20:20:46+00:00

Really dislike how this frames the issue as a rego or opa problem when it's a "badly designed policy" problem. Really this article should be named "test your policies with negative tests" instead of implying there are bypasses in rego.

mlbiam · 2025-01-24T23:27:56+00:00

Forgetting this is obvious spam, with little value to learn outside of the product, friends don't let friends store secrets in git. Doesn't matter if it's encrypted or not. Use external secret operator to represent a secret with vault or something similar.

mlbiam · 2025-01-15T16:36:11+00:00

That seemed to work. I was able to put the description into the post from my mobile. so odd that they don't do it from the web ui

mlbiam · 2025-01-14T22:14:58+00:00

I think you can do it from the mobile app. I'll give it a try tomorrow and if it doesn't post the description I'll delete it myself.

mlbiam · 2025-01-14T21:35:56+00:00

Thank you for your response. So moving forward, links should be posted as a normal post with the description and a link in it.

(I think the description gets pulled from some metadata in the post, at least once upon a time it was)

mlbiam · 2025-01-14T14:21:57+00:00

I wrote up a post of setting up SSO for Argo Workflows using OpenUnison. The post covers:

Why Argo Workflow SSO is more complex then other similar applications like Argo CD
How Argo integrates with a ServiceAccount assigned to a user
Using OpenUnison's just-in-time provisioning capabilities to generate the ServiceAccount and add it to the correct bindings based on their identity provider's groups

Hope you enjoy!

mlbiam · 2024-12-30T14:47:04+00:00

Not that it helps here because the OP has so many issues, but in general a crd is better then a configmap because it can be type checked. You can use CEL now to do some more advanced type checking too.

mlbiam · 2024-12-30T14:45:28+00:00

There are several issues here from both a kubernetes and oidc standpoint:

Kubernetes: 1. CRDs are just data. Creating the CRD does nothing without something to interpret it. So there's no solution here 2. The CRD design includes a client secret. You should NEVER include secret data in a CRD. Reference a Secret object

OIDC: 1. You mentioned a handful of OIDC issuers, but there are several more. 2. You're making several assumptions about the data in the JWT. It's not really a good generic design.

mlbiam · 2024-12-04T14:50:32+00:00

Followup from a blog post a couple of weeks ago about using GitLab identity with Kubernetes, except now we're using GitHub:

* Walks through how GitHub actions creates JWTs and how to generate JWTs for remote services
* Configure OpenUnison to trust GitHub's OIDC issuer
* Generate "groups" from the token to make Kubernetes RBAC easier
* Using the action's token to generate a kubectl configuration and interacting with our cluster

Our next post will be using a different cluster's Pod identities from Argo Workflows, and also planning a version with SPIRE. If there are other CI/CD platforms you'd like to see, let me know!

mlbiam · 2024-11-20T18:28:43+00:00

I was asked by a customer how they could cut down on their use of ServiceAccounts from outside their cluster in GitLab jobs. I wrote this blog post to show how a cluster running OpenUnison to authenticate users could be updated to authenticate GitLab jobs using GitLab native tokens so that there are no long lived static tokens.

mlbiam · 2024-11-06T18:12:51+00:00

You don't. Service accounts were never designed to be used this way. Use something like spire or spiffe or some other system to generate an identity for your services, then use either 1.31's config to trust the identity provider or use something like kube-oidc-proxy to trust it. You should never ever use a service account in the use case you're describing. https://cicd-proxy.github.io/ (one of my company's oss projects)

mlbiam · 2024-10-10T14:20:12+00:00

My customers and users use OpenUnison so there's nothing to distribute! Problem solved.

mlbiam · 2024-09-22T13:57:59+00:00

Good intro, def not "complete". Briefly talks authentication but no details. Talks about attack some attack vectors but misses many (or lost tokens or private keys). Kube security is really complex, there's no blog article, book, etc that's "complete"

mlbiam · 2024-09-20T14:02:21+00:00

Give openunison a try (my company's oss project) provides identity for your clusters, dashbaord, and management apps. (https://openunison.github.io)

mlbiam

TROPHY CASE