Change Details

While the cassandra cluster will be installed on real iron, we want to deploy the corresponding application, kask, on kubernetes. The reason is we expect we'll set up other copies of this service running on kubernetes. We don't want to have an etherogeneous execution environment, but at the same time we want relatively security sensitive stuff like user sessions not to share the same kernel as other less security sensitive applications. Luckily in kubernetes it's easy to add nodes to the cluster with annotations that can then be used during deployments to select which nodes an application will run on. So we can run security-sensitive applications in a different tier than the other ones, on separate servers. In this specific case, I see two possible solutions: - we add the cassandra nodes to kubernetes as "session-service-only" nodes, so that we basically get the applicaiton to run on the same servers as where the datastore is - we add a more generic "privacy" tier of kubernetes nodes, probably just VMs for now, dedicated to running all applications with access to higher security-sensitive data, and run the service there. I see advantages in both approaches, but I think the latter would be more flexible and make more sense on the long run.

While the cassandra cluster will be installed on real iron, we want to deploy the corresponding application, `kask`, on kubernetes, using the deployment pipeline. The reason is we expect we'll set up other copies of this service running on kubernetes. We don't want to have an heterogeneous execution environment, but at the same time we want to compartmentalize relatively security sensitive stuff like user sessions from the rest of the applications (which are less security sensitive and might process arbitrary user input) Luckily in kubernetes it's easy to add nodes to the cluster with annotations that can then be used during deployments to select which nodes an application will run on. So we can run security-sensitive applications in a different tier than the other ones, on separate servers. In this specific case, I see two possible solutions: - we add the cassandra nodes to kubernetes as "session-service-only" nodes, so that we basically get the application to run on the same servers as where the datastore is - we add a more generic "privacy" tier of kubernetes nodes, probably just VMs for now, dedicated to running all applications with access to higher security-sensitive data, and run the service there. I see advantages in both approaches, but I think the latter would be more flexible and make more sense on the long run.

While the cassandra cluster will be installed on real iron, we want to deploy the corresponding application, kask`kask`, on kubernetes, on kubernetesusing the deployment pipeline. The reason is we expect we'll set up other copies of this service running on kubernetes. We don't want to have an ethheterogeneous execution environment, but at the same time we want to compartmentalize relatively security sensitive stuff like user sessions not to sharefrom the rest of the same kernel as otherapplications (which are less security sensitive applications.nd might process arbitrary user input) Luckily in kubernetes it's easy to add nodes to the cluster with annotations that can then be used during deployments to select which nodes an application will run on. So we can run security-sensitive applications in a different tier than the other ones, on separate servers. In this specific case, I see two possible solutions: - we add the cassandra nodes to kubernetes as "session-service-only" nodes, so that we basically get the applicaitontion to run on the same servers as where the datastore is - we add a more generic "privacy" tier of kubernetes nodes, probably just VMs for now, dedicated to running all applications with access to higher security-sensitive data, and run the service there. I see advantages in both approaches, but I think the latter would be more flexible and make more sense on the long run.