I just deleted 1,372 disks from Google cloud and 7 project spaces.
-
Scott Williams 🐧replied to Scott Williams 🐧 last edited by
@Viss @arichtman @mttaggart This is especially concerning given that most k8s deployments don't have any kind of RBAC setup at all. The gears are there for it, but few (Openshift and Rancher being notable exceptions) implement it.
-
@vwbusguy @Viss @mttaggart yea that's read to me like a `TODO` that's disgustingly overdue. Either implement something or add the extension API points. The hacks that are the secrets CSI driver or external-secrets operator are not good enough imho
-
@vwbusguy @arichtman @mttaggart one time i made a very attractive lady literally snotlaugh by saying "kubernetes appears to have been invented to solve a litany of problems that nobody actually appears to have"
-
@Viss @vwbusguy @mttaggart from the documentary it was basically shared to kill competition. Not exactly an auspicious start. It's also born of Google Borg which itself is presumably of requirements that afflict barely any other enterprises. Using kubernetes is not that far off saying "well Airbus use ramjet turbines so our hatchback coupe should"
-
@arichtman @Viss @mttaggart Istio is absolute overkill for most setups. The overhead is insane. If you want to keep things simple, use the Wireguard backend for flannel and let cert-manager autoprovision TLS for everything you deploy.
-
Scott Williams 🐧replied to Max Effort last edited by [email protected]
@kubefred @arichtman @Viss @mttaggart If it's strictly for network policy, calico is probably more practical.
Istio can do some really cool stuff for securing cross cluster Kubernetes traffic, but it's still a ton of overhead. There's also submariner for doing that more simply.
-
@vwbusguy @Viss @mttaggart work-wise my hands are more tied as we're EKS. Home-wise I'm banning cillium and just leaving east-west traffic alone. If you're in my shit, you're in my shit. I'll get to securing when I consider anything prod grade and that means backups, DR, monitoring etc
-
@arichtman @Viss @mttaggart Why select nodes as dmz when you can put a proxy in front of it and only expose what you really intend to?
-
@vwbusguy @Viss @mttaggart we don't do that but in cases like MetalLB or for arbitrary TCP routing it may be required.
-
Scott Williams 🐧replied to Ariel last edited by [email protected]
@arichtman @mttaggart @Viss My garden shed is secured like how old tomcat servers are - it's full of unusual spiders and I'm not sure which ones are still alive and which ones might be highly toxic to touch. No one is going in there.
-
@Viss @mttaggart @arichtman I'm guessing this was meant as a reply for a different thread? That said, having experienced something similar before myself, this is solid advice.
-
Scott Williams 🐧replied to Scott Williams 🐧 last edited by
@Viss @mttaggart @arichtman Reading the Phoenix Project was both highly therapeutic but also very difficult because it made me remember fresh some of those experiences.
-
@arichtman @Viss @mttaggart Oh, there's ways to do it, such as SOPS or a number of vault vendors that manage secrets or do runtime injection (currently using Infisical, but that's not an endorsement).
Manage Kubernetes secrets with SOPS
Manage Kubernetes secrets with SOPS, OpenPGP, Age and Cloud KMS.
(fluxcd.io)
-
@vwbusguy @arichtman @mttaggart ive been telling my customers to handle secrets entirely out of band from ci/cd. and to basically have them deployed in a way where they are more or less hard-coded and encoded somehow, so they dont end up in text files on disk or in env vars
-
Scott Williams 🐧replied to Scott Williams 🐧 last edited by
@arichtman @Viss @mttaggart Yes, k8s secrets could be better, but they're still an improvement over the past days where people hard coded credentials into their git repos assuming they'd never be public and/or thought they'd be safe just because they were compiled into a jar or war file and no one would dare peak inside, right?
-
Scott Williams 🐧replied to Viss last edited by [email protected]
@Viss @arichtman @mttaggart This just tells me you didn't have the wonderful joy of trying to run Docker Swarm in production in its early days and I'm happy for you in that regard. Sweet glory did Kubernetes solve a lot of problems compared to that.
-
@vwbusguy @Viss @mttaggart SOPS only handles encryption in at rest in repo afaict, nothing runtime and only applicable to pure gitops. Out of band secrets still involves non-core controllers or features and often they have to create core `secret` resources which defeats most of the point of having the secrets secured externally - unless I'm missing something...
-
@vwbusguy @arichtman @mttaggart this feels like one of those sorta 'if you go back further in time, you see that docker actually introduced a lot of problems, which were then fixed by k8s' scenario, so if your context window begins at docker, then yeah its a 'measurable improvement', but if it begins 'before you installed docker', then you're still at a net negative
-
Scott Williams 🐧replied to Scott Williams 🐧 last edited by [email protected]
@Viss @arichtman @mttaggart I literally wrote my own CNI before I realized what I was doing just trying to get a reliable network service that I could proxy between containers with it. It constantly called etcd to splice in config updates to nginx with regex on changes on each of the hosts with logic to proxy sub paths, etc.
-
Scott Williams 🐧replied to Scott Williams 🐧 last edited by
@Viss @arichtman @mttaggart I never published it because it felt so dirty and I didn't want to maintain it and it was a problem I didn't have to solve with Kubernetes.