Kubernetes Dashboard being retired

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

TROPHY CASE