-
Notifications
You must be signed in to change notification settings - Fork 4
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Reflecting on the security model for pipelines in a multi-tenant context #77
Conversation
Input from @bigkevmcd, I wonder if for the cross-namespace problem, we couldn’t do something like this |
2f50aca
to
06cc32f
Compare
kind: Pipeline | ||
metadata: | ||
name: invalid-search-shared-environment | ||
namespace: billing #invalid pipeline namespace |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Presumably the search tenant has no permissions to add a pipeline to the billing
namespace right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Didn't get to review all of it but this is how far I got.
A new custom resource definition `Pipeline` lets users define a pipeline for a specific application and its associated target environments in a central place. | ||
Each pipeline is represented by a single resource consisting of an application reference and a list of all the environments in turn consisting of a list of the environments' targets. | ||
The order of environments is mandated by each environment's position in that list. An application reference within a `Pipeline` resource consists of a kind and a name. | ||
Together with the namespace declared in each target, the application is uniquely identified per-target. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Has anything been changed here except for the line wrapping? It's hard to tell.
|
||
## Summary | ||
|
||
This rfc proposes the security posture required for pipelines to securely work in a weave gitops enterprise multi-tenant environment. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This rfc proposes the security posture required for pipelines to securely work in a weave gitops enterprise multi-tenant environment. | |
This RFC proposes the security posture required for pipelines to securely work in a weave gitops enterprise multi-tenant environment. |
[pipelines rfc](../0001-pipelines/README.md) indicates the approach to use to define a delivery pipeline to deliver | ||
an application across multiple environments. | ||
|
||
Weave Gitops Enterprise will host multiple applications owned by multiple teams being delivered across multiple environments. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Weave Gitops Enterprise will host multiple applications owned by multiple teams being delivered across multiple environments. | |
Clusters running Weave Gitops Enterprise will host multiple applications owned by multiple teams being delivered across multiple environments. |
That multi-tenancy nature, and how to keep the isolation between tenant to ensure that any of them could use | ||
pipelines safely is the main goal of this RFC. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should be more specific here as this RFC exclusively solves challenges in the context of pipelines, nothing else.
|
||
### Non-Goals | ||
|
||
- We picture tenant as a static image but in reality,a tenant would evolve. this evolution is out scope. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure I understand what this is supposed to bring across. Does this RFC only apply to a specific model of tenant isolation?
For the proposal we are going to use the following scenario. | ||
|
||
**Organisations by Tenancy models** | ||
We are going to define two organisation, each one with a different tenancy model. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We are going to define two organisation, each one with a different tenancy model. | |
We are going to define two organisations, each one with a different tenancy model. |
Moving to in progress to review it in the context of latest design decisions |
**Organisations by Tenancy models** | ||
We are going to define two organisation, each one with a different tenancy model. | ||
- `shared-environments` where tenants are isolated at the level of the namespace. Each tenant owns a namespace within each environment/cluster. | ||
- `dedicated-environments` where tenants are isolated at the level of the environment. Each tenant owns an entire cluster. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We could use the names referenced here https://kubernetes.io/blog/2021/04/15/three-tenancy-models-for-kubernetes/. It may help particularly in any external documentation to be able to cross reference
closing PR as need to review the scope of the document ... not deleting PR as the issue still open |
should close weaveworks/pipeline-controller#25