Hey, I'm looking for an Ingress for Kubernetes thas is built to be secure and to be used on self-hosted ("on-premise") clusters.
* Use certificates from secrets in another namespace (specified in advance) if possible without having access to all secrets in all namespaces
=> Those are wildcard Let's Encrypt certificates managed by cert-manager (until I find another application that doesn't read secrets of whole namespace), I want to deploy multiple applications and to re-use wildcard certificates.
=> I don't want to copy the certificates in multiple namespaces.
=> bye ingress-nginx, traefik or anything relying on the Ingress resource, not supporting that feature on purpose for "security" reasons that are never explained (tell me what I'm missing in RBAC).
* Offer a way to upgrade without any downtime on any connection (although I'll never notice that in my current setup), while using hostPort for ports 80 and 443 (just like I can do with nginx on host)
=> I don't want to use firewall rules on the host to redirect on a NodePort, unless you prove me there is no other way and it is a good practice (I don't want to loose source IP so it would be SNAT?).
=> Since I bind on host ports 80/443, I can't use rolling update, so it needs to update inside the container itself without restart.
=> Maybe it's possible to use SO_REUSEADDR to be able to run multiple pods on the same port?
* Be easy to use with a PodSecurityPolicy.
=> not with a lot of deployments with different service accounts
I'm starting to brainstorm that project since there is no solution to my madness :)
User policy for allowing access to a single bucket:
@matrix When you start using users, OpenID, policies, it's not that easy. And MinIO client is weird to automate.
In my experience, existing contributors who are comfortable in their workflow is a known value, and thereotical new contributors who might be more comfortable in a different workflow is an unknown value. I would sooner cater to the former group, who have already demonstrated a history of consistent contributions under an existing workflow.
This is why sway and wlroots are still on GitHub, despite the fact that, you know, I am the CEO of a competing service. I am in a position to force these projects to move to sr.ht, but it would be disruptive, risk alienating established contributors, and likely be a net negative for the project.
Je suis à la recherche d'un (ou plusieurs) article/dossier qui explique à un public non expérimenté la collecte des données personnelles, les échanges de ces données entre services et le système publicitaire des enchères, ainsi que le point de vue légal avec le RGPD. Un livre pourrait être pas mal mais ça semble plus difficile à partager et aborder dans ce cas-là.
J'ai les connaissances mais j'ai du mal à conseiller un document où tout est rédigé/expliqué correctement.
The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!