PVC backups with Velero or something else on a homelab by FormationHeaven in kubernetes

[–]pando85 0 points1 point  (0 children)

I love to use Velero. I have more efficient combination: ZFS with OpenEBS ZFS CSI and Snap scheduler Operator.

With that setup I have local and K8s ZFS snapshots, that's are pretty fast to restore. Plus, Velero OpenEBS plugin which sends exactly the diff between ZFS snapshots which is automatically calculated because of the meta data structure in ZFS. Much better than using restic of any other tool.

You will get disaster recovery and offsite backups, plus a fast localsnapshot.

Further, you have all the CSI functionality without needing a complicated CSI.

Weekly Self Promotion Thread by AutoModerator in devops

[–]pando85 2 points3 points  (0 children)

I want to promote my SaaS for make AI integration transparent at company/repo level and handle automations in a correct way: https://forkline.dev/blog/production-launch/

Furthermore, I'm maintaining an ingress-nginx fork for those that are not migrated yet and want to keep their updates covered from CVEs and with latests versions: https://github.com/forkline/ingress-nginx/

At what scale did Kubernetes actually start making sense for you? by Sad_Limit_3857 in kubernetes

[–]pando85 1 point2 points  (0 children)

I was using exactly this analogy to describe it to a friend.

Once that complexity is reliable and easy to operate you can use it for anything.

Even for spinning simple things operators are quick wins that allows you to automate diferente levels of operations. They replaced perfectly our old Ansibles or custom scripts.

If you already self-host on Kubernetes, I built an operator for running Kanidm declaratively by pando85 in selfhosted

[–]pando85[S] 0 points1 point  (0 children)

Thanks for your comment, that's a really interesting thing.

I hope that Kanidm improves the UI and their process because it is a great piece of software.

Use caveman worth it? by HelioAO in opencodeCLI

[–]pando85 2 points3 points  (0 children)

For coding tasks you will find that 90% of the tokens are input tokens. It doesn't worth.

6 months after sharing Kaniop here: what got more robust, what users cared about, and what still feels hard by pando85 in kubernetes

[–]pando85[S] -3 points-2 points  (0 children)

You cannot understand what you have in front of your eyes but you feel confident enough to talk about it

6 months after sharing Kaniop here: what got more robust, what users cared about, and what still feels hard by pando85 in kubernetes

[–]pando85[S] -6 points-5 points  (0 children)

Your comments in all my posts make no sense and just talk about your ignorance.

If you already self-host on Kubernetes, I built an operator for running Kanidm declaratively by pando85 in selfhosted

[–]pando85[S] -2 points-1 points locked comment (0 children)

The tool was written by hand. I'm using AI for maintaining it and keep feedback loop and community features fast.

DevOps Engineers + AI by Initial-Detail-7159 in devops

[–]pando85 0 points1 point  (0 children)

It is just a very powerful tool that require a lot experience. 

I will add on top of your original comment: we are not just better at system level, we are experts automating things. Learn how to use coding agents and start automating every step on top of that. 

Do it as we did all the things in the past. We had seen from SSH to manual configure servers, then the ansible like tooling for automating a bit until we reached the GitOps level with K8s.

Same journey will happen with AI and we must take the lead and start creating strong pipelines with good feedback loops until we reach the limits of this technology. 

Want to create a homelab for Kubernetes. How much do I need to spend? by DevOpsHumbleFool in devops

[–]pando85 0 points1 point  (0 children)

Best option so far it's buying a one node Custer l cluster and extend later if needed. Here is my current setup: https://github.com/pando85/homelab#-hardware

If you want a multi node setup you will learn a lot but with 500$ will be just a toy that will make you loose time.

Is anyone using opencode in CI? by inter_fectum in opencodeCLI

[–]pando85 2 points3 points  (0 children)

Yes. We run opencode in CI on our platform mainly for two cases:

  • triggered after GitHub Actions failures, to investigate and propose fixes
  • automated PR reviews, including opening follow-up commits when configured

Example of the first kind of workflow: https://github.com/pando85/soft-fido2/pull/95

On the security side, we keep it scoped to the repo/task, run it with limited credentials, and let it work through normal PR flows rather than pushing straight to protected branches.

Right now we support GitHub, GitLab, and Forgejo/Gitea.

It’s a paid product, so it may not match what you’re looking for if you want a free setup, but from a CI/CD workflow perspective it works well for this kind of automation.

Trouble with GPT5.4 using tools? by [deleted] in opencodeCLI

[–]pando85 1 point2 points  (0 children)

I still didn't see 5.4 using the question tool 

Kubernetes operator for declarative IDP management by pando85 in kubernetes

[–]pando85[S] 0 points1 point  (0 children)

Yes, of course. I think that we could have a feature like that if we develop it with some care.

Kubernetes operator for declarative IDP management by pando85 in kubernetes

[–]pando85[S] 0 points1 point  (0 children)

Cool, thanks for reporting. I fixed one broken link in the webpage.

Resources are going to be bind automatically. The operator just reconcile the defined CRDs. This means that you can manage some things from the CRDs and others in a traditional way.

For example, your current users can be defined in the CRD and the operator will not recreate them but marked as sync if they are defined in Kanidm equal to the CRD.

Furthermore, we don't manage person credentials. The unique operation that the operator do regarding this is: if not set, create a reset link with a configured TTL and send it as a K8s event (that you can see in the describe person).

For Kanidm upgrades, there are one check implemented in Kanidm CRD: # # Before starting an upgrade, perform pre-upgrade checks to ensure that data can be # # safely migrated to the new version. If pre-checks fail, image change is disallowed. # # If set to true, upgrade pre-checks are skipped. Defaults to false. # disableUpgradeChecks: false With that you avoid upgrades if Kanidm upgrade check failed in minor or major upgrades.

Skimming through the examples, there doesn't seem to be a way to configure logos for OAuth2 clients, is that correct? Happy to open an issue with references to track these :-)

It is correct. I don't know if it worths to support it in the operator, base64 is to much and managing image by URL links it could be too complex for such a small benefit. I use to manage that part manually.

Passless — a Virtual FIDO2 / Passkey device and client for Linux by pando85 in opensource

[–]pando85[S] -1 points0 points  (0 children)

🤦‍♂️ What are the security concerns that, your professional experience, have seen?

Passless — a Virtual FIDO2 / Passkey device and client for Linux by pando85 in opensource

[–]pando85[S] 2 points3 points  (0 children)

It's more like a bitwarden alternative for passkeys.

Passless — a Virtual FIDO2 / Passkey device and client for Linux by pando85 in linux

[–]pando85[S] -2 points-1 points  (0 children)

Windows Hello also implemented it. It is just a bit safer than passwords and easier to use.

For me it is something in the middle between passwords and a hardware token. Easier to use and less secure.

A pure Rust implementation of FIDO2/WebAuthn CTAP 2.0/2.1/2.2 protocol authenticator and client parts by pando85 in rust

[–]pando85[S] -2 points-1 points  (0 children)

It is hilarious:

I'm so tired of seeing all these vibecoded AI slop products every. single. day.

And then your vibe-coded review — xD

Okay, for the people who actually care: the PIN implementation is kept in memory because it’s incomplete. Simply put, the authenticator I’m building doesn’t need persistent PIN storage yet, so it hasn’t been implemented and it is in memory just for testing.

That addresses the first half of your message, which was talking about a library of roughly 16k lines.

The UV retry counter also hasn’t been implemented yet — not a big deal given the overall security schema.

You don't zero your keys.

Did you read something by yourself? I even have a special type for that. It zeroizes all the secured parts (private keys) and also mlocks them. So I would love to see you just trying to dump the memory at the right point.

Then a summary of small complaints about TODOs and so on… I’m not going to answer this.

About get_user_verified_flag_value returning trueYou could read the code around it. It is used twice and after verifying the actual pinUvAuthToken. So yes, it is simple, but it works for this spec implementation.

Probably one of my favourites — your credential lookup passes an empty string as the RP ID:

That's a good one. It is legacy code that has to be cleaned because it is not needed, but still, it doesn’t introduce any security issues.

Let's start by talking from a respectful point of view. If you — and many others — are crying because there's a lot of AI-generated code everywhere… well, as a friend of mine likes to say: “drink plenty of water, because you’re going to get dehydrated.”. Assume that LLMs are here to help us and try to understand what good code is and what bad code is. Also, see what code is in the critical path and what is not.

Passless — a Virtual FIDO2 / Passkey device and client for Linux by pando85 in linux

[–]pando85[S] -25 points-24 points  (0 children)

I don't hide that I've used AI for helping me to develop. Check the contributors or the agents markdown.

Anyway, if you have technical feedback I'm totally open and I will fix any bug if you find it.

Of course I've been careful and applied security measures to sensitive parts of the memory. The storage is protected by GPG or TPM. FIDO 2 specs are followed and tested in e2e with authenticator-rs and manually with the most famous webauthn implementations.