mblomdahl/tfc-vs4345-k8s

Build it like a SaaS!

Opened this issue · 0 comments

mblomdahl commented

What do we want to achieve?

Flexible infrastructure so that we can scale out efficiently to multiple deployments and achieve good resource utilization.

Strategy:

  1. Share Kubernetes cluster [x]
  2. Share RDS database manager [x]
  3. Share S3 bucket [-]
  4. Share Auth0 tenant [-]

What's the next thing we need to do?

Share S3 Bucket Between Studio Deployments

Context: VS-4570 Dev Story under Kubernetes epic

Share the S3 bucket by prefix, i.e. passing in my-bucket/deployment-prefix-1 to one Studio setup and passing my-bucket/deployment-prefix-2 to another Studio setup results in both co-existing peacefully.

Considerations:

  1. Security, all S3 access needs to be filtered through a) startsWith(bucketAndRootPath), and b) forbid relative ../../../anotherRoot/ look-ups (probably not used/supported anyway)
  2. Compatibility, any legacy per-deployment bucket setups should work exactly as before
  3. Migration support, how to move an existing Studio deployment into the new structure...? Maybe we won't.

Open questions:

  1. Consistency, what kind of root path should be allowed? I think the pattern my-bucket/<env type>/<product>/<external URL> makes sense, e.g. mb-eks-vs7-bucket/prod/studio/vs7-studio.mb-ek....

Share Auth0 Tenant Between Studio Deployments

Context: VS-4571 Top-level Epic alongside Kubernetes

What are the pre-requisites for sharing (and caring for) the same Auth0 tenant?

  1. Each Studio setup have their own:
    1. Clients
    2. VS-4572 Roles, and
    3. Permissions
  2. Users exists in a shared directory and can be (de)authorized Roles (permissions) on the Studio setups they should have access to
    1. VS-4573 Enable Google connection
    2. VS-4574 Enable Azure AD connection
    3. VS-4575 Do not allow a Studio setup to manage the One Default Super User account
    4. Users have no authorizations at all until explicitly invited/granted
  3. Change signing algorithm to HS256 so that we can issue our own tokens as needed

Dev Task: Own Auth0 Roles per Studio Setup

Context: VS-4572 Dev Story under Share Auth0 epic

Auth0 roles and role assignments should be namespaced with their respective Studio setup, i.e. "mb-eks-studio|ViewSpotServer User" instead of just "ViewSpotServer User". This allows the Studio deployment to function within the same Auth0 context as another Studio deployment without role assignments "spilling over".

Acceptance criterion:

  • When retrieving/listing roles, filter the roles list so that only roles namespaced with the current deployment are exposed (can be achieved using the vendor ?name_filter=my-studio query parameter, for example)
  • When creating roles, add the namespace to the role friendly name
  • When updating/deleting roles, ensure that the current namespace

Dev Task: Enable Google Connections for Auth0

Context: VS-4573 Dev Story under Share Auth0 epic

Dev Task: Enable Azure AD Connections for Auth0

Context: VS-4574 Dev Story under Share Auth0 epic

Dev Task: Remove Auth0 setup of the One Default Super User account

Context: VS-4575 Dev Story under Share Auth0 epic

Dev Task: Switch JWT Signing Algorithm to HS256

Context: VS-2038 Dev Story under Share Auth0 epic

Change signing algoritm to HS256 so that we can issue our own tokens as needed.