Things learned last week: Kubernetes operators are a huge pain for security reviews. You basically have to reverse engineer the app to figure out what holes it'll open in your cluster.
-
-
take a look at https://www.cncf.io/blog/2019/06/20/virtual-cluster-extending-namespace-based-multi-tenancy-with-a-cluster-view/ …. solve this exact problem. one api server per operator, but the node pool are shared (optionally isolated with secure container)
Hvala. Twitter će to iskoristiti za poboljšanje vaše vremenske crte. PoništiPoništi
-
-
-
Even trivial workloads will be deployed and lifecycled with automation. Seems advantageous to have that automation in the cluster as a controller than outside in some other form. Maybe we just need better visibility into what the operator can do?
-
If the automation is some outside system or person applying static manifests, including ClusterRoles and such, how would you do a security review of that, and is that really better? Maybe it's easier because manifests are easier to review than go code?
Kraj razgovora
Novi razgovor -
-
-
I already wrote a lot of operators, but none of them had the need to create roles and bindings on its own. I statically create a role with only the permissions the operator needs and bind that.
Hvala. Twitter će to iskoristiti za poboljšanje vaše vremenske crte. PoništiPoništi
-
Čini se da učitavanje traje već neko vrijeme.
Twitter je možda preopterećen ili ima kratkotrajnih poteškoća u radu. Pokušajte ponovno ili potražite dodatne informacije u odjeljku Status Twittera.