6 ms·

While the use of namespaces seemed a bit discounted in the article, I think part of the problem is that it's an underutilized and poorly conveyed feature, but m

While the use of namespaces seemed a bit discounted in the article, I think part of the problem is that it's an underutilized and poorly conveyed feature, but maybe that's just me? I'd like to see a better out-of-the-box vanilla K8S user management interface in the dashboard. Maybe the default UX on cluster creation is a user/service account that isn't cluster admin that is limited to 1 or more namespaces. There should be a better dashboard to configure and create users that is front and center when you first create a cluster. You have to work a bit to get something you can use to authenticate as cluster admin like role. This should help direct people towards creating more users and isolated namespaces.

justicezyx 8y ago
Also gVisor.
halbritt 8y ago
My org is using namespaces for tenant isolation. Works quite well.
- geerlingguy 8y ago
  Namespaces++. Unless you’re just running one app in a Kubernetes cluster (where default == that app), namespaces solve a plethora of problems.
  - halbritt 8y ago
    Resource limits, network policy boundaries, etc.
    - smarterclayton 8y ago
      That’s what we designed them for :) I do think we’ve not explored enough of the per namespace policy stuff though - i’d like both podpreset and a reasonably simple scheduling policy (toleration + node selector control to replace the annotation based system) to make it in, as well as a simpler namespace initialization path so you can more easily lock down the contents of a namespace without having to proxy the create namespace API call.
      - halbritt 8y ago
        By podreset are you referring to something like poddisruptionbudget? Because it'd be neat to define that on a per namespace basis.
        smarterclayton 8y ago
        PodPreset went alpha with service catalog but hasn’t made it out to beta yet. It makes certain forms of injection / rules easier (you must use a standard log dir, you should use the provided HTTP_PROXY vars, etc). https://kubernetes.io/docs/concepts/workloads/pods/podpreset/ https://kubernetes.io/docs/concepts/workloads/pods/podpreset... Being able to limit a user to only being able to edit one pod preset or scheduling policy (via rbac name access) would provide some useful flexibility for splitting control between admin and namespace user.
        halbritt 8y ago
        Okay, I get what your point. I'm still living in the world where operating a platform for the benefit of a set of developers entails building and operating a set of services that abstracts the details of the infrastructure sufficiently that these things don't matter.
ec109685 8y ago
Agree, I'm not sure what the author is getting at here: "Compounding this is the fact that most Kubernetes components are not Tenant aware. Sure you have Namespaces and Pod Security Policies but the API itself is not. Nor are the internal components like the kubelet or kube-proxy. This leads to Kubernetes having a “Soft Tenancy” model." That's like saying the Hypervisor isn't "tenant" aware.
raesene9 8y ago
+10000 User admin and the reliance on client-cert authentication is one of the biggest weaknesses I see in k8s security at the moment. There are obviously other options like OIDC available, but it can be tricky to set up and isn't on by default, so instead client certs are used for user auth. and given the lack of certificate revocation, they're really not suited for that.

justicezyx 8y ago

Also gVisor.

halbritt 8y ago

My org is using namespaces for tenant isolation. Works quite well.

geerlingguy 8y ago
Namespaces++. Unless you’re just running one app in a Kubernetes cluster (where default == that app), namespaces solve a plethora of problems.
- halbritt 8y ago
  Resource limits, network policy boundaries, etc.
  - smarterclayton 8y ago
    That’s what we designed them for :) I do think we’ve not explored enough of the per namespace policy stuff though - i’d like both podpreset and a reasonably simple scheduling policy (toleration + node selector control to replace the annotation based system) to make it in, as well as a simpler namespace initialization path so you can more easily lock down the contents of a namespace without having to proxy the create namespace API call.
    - halbritt 8y ago
      By podreset are you referring to something like poddisruptionbudget? Because it'd be neat to define that on a per namespace basis.
      - smarterclayton 8y ago
        PodPreset went alpha with service catalog but hasn’t made it out to beta yet. It makes certain forms of injection / rules easier (you must use a standard log dir, you should use the provided HTTP_PROXY vars, etc). https://kubernetes.io/docs/concepts/workloads/pods/podpreset/ https://kubernetes.io/docs/concepts/workloads/pods/podpreset... Being able to limit a user to only being able to edit one pod preset or scheduling policy (via rbac name access) would provide some useful flexibility for splitting control between admin and namespace user.
        halbritt 8y ago
        Okay, I get what your point. I'm still living in the world where operating a platform for the benefit of a set of developers entails building and operating a set of services that abstracts the details of the infrastructure sufficiently that these things don't matter.

ec109685 8y ago

Agree, I'm not sure what the author is getting at here: "Compounding this is the fact that most Kubernetes components are not Tenant aware. Sure you have Namespaces and Pod Security Policies but the API itself is not. Nor are the internal components like the kubelet or kube-proxy. This leads to Kubernetes having a “Soft Tenancy” model." That's like saying the Hypervisor isn't "tenant" aware.

raesene9 8y ago

+10000 User admin and the reliance on client-cert authentication is one of the biggest weaknesses I see in k8s security at the moment. There are obviously other options like OIDC available, but it can be tricky to set up and isn't on by default, so instead client certs are used for user auth. and given the lack of certificate revocation, they're really not suited for that.