Skip to content

Don't limit CODER_NAMESPACE to a single namespace #5

@hh

Description

@hh

From https://kubernetes.io/docs/concepts/overview/working-with-objects/namespaces/ :

There are benefits to deploying per-user namespaces:

  • Ability to give the user control over their own namespace via RBAC (deploying other objects / API Isolation)
  • Ability to persist expensive objects like cert-manager certs / let encrypt (some objects take a lot of time)
  • Ability to isolate traffic between multiple users / namespaces

We create a namespace per user, and do not destroy it when a workspace is torn down. This allows expensive objects (like cert-manager/letsencrypt certs/dns) to persist and be reused for multiple workspaces (from the same user) to access them.

Some resources we use per user/namespace:

  • Issuer (Cert-Manager w/ DNS01 for wildcard)
  • Certificate (this can take 40 seconds to provision from Lets Encrypt)
  • tls-secret (generated by TLS Cert from Certificate)
  • wildcard ingress (each user get's there own namespace AND *.username.coder.website [accessible without coder])
  • RoleBinding w/ admin over their own namespace (we allow them to create whatever other resources they want within their namespace) : RBAC
  • We use Resource Quotas to ensure one user doesn't take over all the resources on a node

Metadata

Metadata

Assignees

Labels

enhancementNew feature or request

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions

    pFad - Phonifier reborn

    Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

    Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


    Alternative Proxies:

    Alternative Proxy

    pFad Proxy

    pFad v3 Proxy

    pFad v4 Proxy