From 9f9e1dac7c6d88e83e1e31c3d2e8565e455e3cca Mon Sep 17 00:00:00 2001 From: nicklathe Date: Fri, 21 Jun 2019 15:39:14 -0700 Subject: [PATCH 1/4] Customer onboarding RFC init Signed-off-by: nicklathe --- 0001-customer-onboarding.md | 122 ++++++++++++++++++++++++++++++++++++ 1 file changed, 122 insertions(+) create mode 100644 0001-customer-onboarding.md diff --git a/0001-customer-onboarding.md b/0001-customer-onboarding.md new file mode 100644 index 0000000..d8b669e --- /dev/null +++ b/0001-customer-onboarding.md @@ -0,0 +1,122 @@ +- Feature Name: `scipian_customer_onboarding` +- Start Date: 2019-06-21 +- RFC PR: [scipian/rfcs#1](https://github.com/scipian/rfcs/pull/1) +- Community Issue: [scipian/community#6](https://github.com/scipian/community/issues/6) + +# Summary +[summary]: #summary + +Scipian customer onboarding will allow a seamless process for customers to +onboard to the Scipian platform. At a high level, this includes creation of +namespaces, RBAC rules, and importing Terraform state from a location external +to Scipian. + +# Motivation +[motivation]: #motivation + +There is currently process for a new customer to be onboarded to Scipian. Having +a smooth process in place will be paramount to onboarding multiple customers +who want to use Scipian. Having a low barrier of entry will encourage +teams to use Scipian. + +# Guide-level explanation +[guide-level-explanation]: #guide-level-explanation + +Scipian builds on and uses many Kubernetes primitives. Some of these include +namespaces and RBAC rules. This allows multiple teams to use Scipian, while +keeping each team's data and interactions with Scipian separated from eachother. + +For onboarding a new team to the Scipian platform, the following is created: + +- **Namspace**. A new namespace in the Scipian cluster will be created for a +given team, under a unique name tied to a specific project or application. +- **Role**. This will define a role in Scipian as to what operations are allowed +in the cluster for anyone asigned to that role. It will be tied to the created +namespace, and only allow the least privileges required to create Workspaces and +Runs in Scipian. +- **RoleBinding**. This will bind the created role to a set of users associated +with the onboarding team. + +If a team is already using Terraform to manage their infrastructure, Scipian +supports the importing of Terraform state from a location external to Scipian. +Scipian will pull this state and push it to it's own managed backend. + +Below is the flow when onboarding a new customer to Scipian: + +- New customer requests to be onboarded to Scipian +- Customer provides list of users, (the email associated with the IDP Scipian +uses) of all the members who will need to use Scipian +- A Scipian admin will create the Namespace and RBAC roles for the onboarding +team +- Onboarding team members will use the Scipian Authentication CLI to set up +their kubeconfigs for interfacing Scipian. +- The onboarding team will create a Kubernetes secret in their namespace with +the AWS credentials needed for Scipian to pull Terraform state from an S3 bucket +- Scipian will pull that state into it's own backend +- Customer will then be onboarded and ready to use the Scipian platform + +# Reference-level explanation +[reference-level-explanation]: #reference-level-explanation + +- RBAC rules and Namespace will be created manually by a Scipian admin using +yaml and `kubectl`. This could be automated later via an onboarding UI, but that +is beyond the scope of this RFC. +- Terraform state "puller" will be a Kubernetes job that runs a +special Docker container that will pull state from an S3 bucket, +and place in the appropriate workspace in Scipian's backend. This could be +initiated by a Scipian admin, or an onboarding user. The state puller will need +to map the current Terraform state workspace structure created by `scipctl` to +the new workspace structure that Scipian expects. + +# Drawbacks +[drawbacks]: #drawbacks + +This is a necessary feature of Scipian, and currently no drawbacks have been +identified by adding this feature. + +# Rationale and alternatives +[rationale-and-alternatives]: #rationale-and-alternatives + +The onboarding outlined in this RFC will be an MVP level feature. Later, this +functionality could be extended to include a self service UI, which would +automate RBAC rules and Namespace creation, as well as the pulling of extneral +Terraform state, thereby removing the requirement for a Scipian admin's direct +involvement every time a new customer wishes to onboard to Scipian. + +# Prior art +[prior-art]: #prior-art + +Because Scipian extends Kubernetes and utilizes many of Kubernetes' primitives, +the approach outlined in this RFC will use typical Kubernetes cluster +administration flows to accomplish these tasks, even though it will require +manual action from a Scipian admin. Namely, these resources will be created to +onboard a customer by a Scipian admin using `kubectl` and yaml. Using the +primitives already built into Kubernetes allows us to stay unified with +Kubernetes, build this solution quickly, and iterate to improve this onboarding +process over time. + +# Unresolved questions +[unresolved-questions]: #unresolved-questions + +The following are open questions the Scipian dev community should answer before +work commences: + +- Should the Terraform state "puller", which will be a Kubernetes Job, be +initiated by the onboarding team, or by a Scipian admin? +- Somewhat tied to this process is the question of how best to distribute the +Scipian Authentication CLI to onboarding teams? +- What areas do we need to consider to align us for future iterations and +improvements to automate this process? +- Further research into Terraform will be needed, to determine the best way +to pull state and remap it into Scipian's backend in the correct workspace +structure expected by Scipian. + +# Future possibilities +[future-possibilities]: #future-possibilities + +As mentioned in this RFC, this is an MVP level solution to onboarding. This +process should be automated and include a self service UI in the future, as +the manual action requried by a Scipian admin will not scale. However, this MVP +should be done in a way where future iteration can begin at any time, but the +proposed implementation should support the current needs for the forseable +future. From 2aa87bf0d8fe3ab94aa29ec306101b04dc74b400 Mon Sep 17 00:00:00 2001 From: nicklathe Date: Fri, 21 Jun 2019 15:44:28 -0700 Subject: [PATCH 2/4] Fix RFC PR number Signed-off-by: nicklathe --- 0001-customer-onboarding.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/0001-customer-onboarding.md b/0001-customer-onboarding.md index d8b669e..2ead65e 100644 --- a/0001-customer-onboarding.md +++ b/0001-customer-onboarding.md @@ -1,6 +1,6 @@ - Feature Name: `scipian_customer_onboarding` - Start Date: 2019-06-21 -- RFC PR: [scipian/rfcs#1](https://github.com/scipian/rfcs/pull/1) +- RFC PR: [scipian/rfcs#3](https://github.com/scipian/rfcs/pull/3) - Community Issue: [scipian/community#6](https://github.com/scipian/community/issues/6) # Summary From f832bf8b8ae974469eb38bf8bad9e4a198127ea0 Mon Sep 17 00:00:00 2001 From: nicklathe Date: Wed, 3 Jul 2019 14:06:40 -0700 Subject: [PATCH 3/4] Fix typos --- 0001-customer-onboarding.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/0001-customer-onboarding.md b/0001-customer-onboarding.md index 2ead65e..219cc6a 100644 --- a/0001-customer-onboarding.md +++ b/0001-customer-onboarding.md @@ -14,7 +14,7 @@ to Scipian. # Motivation [motivation]: #motivation -There is currently process for a new customer to be onboarded to Scipian. Having +There is currently no process for a new customer to be onboarded to Scipian. Having a smooth process in place will be paramount to onboarding multiple customers who want to use Scipian. Having a low barrier of entry will encourage teams to use Scipian. @@ -24,7 +24,7 @@ teams to use Scipian. Scipian builds on and uses many Kubernetes primitives. Some of these include namespaces and RBAC rules. This allows multiple teams to use Scipian, while -keeping each team's data and interactions with Scipian separated from eachother. +keeping each team's data and interactions with Scipian separated from each other. For onboarding a new team to the Scipian platform, the following is created: From dcac33158804378df481cec4ae637cb86c31a6b4 Mon Sep 17 00:00:00 2001 From: nicklathe Date: Tue, 9 Jul 2019 10:59:46 -0700 Subject: [PATCH 4/4] Remove state migration portion in RFC --- 0001-customer-onboarding.md | 40 ++++++++++--------------------------- 1 file changed, 11 insertions(+), 29 deletions(-) diff --git a/0001-customer-onboarding.md b/0001-customer-onboarding.md index 219cc6a..7a44f67 100644 --- a/0001-customer-onboarding.md +++ b/0001-customer-onboarding.md @@ -1,6 +1,6 @@ - Feature Name: `scipian_customer_onboarding` - Start Date: 2019-06-21 -- RFC PR: [scipian/rfcs#3](https://github.com/scipian/rfcs/pull/3) +- RFC PR: [scipian/rfcs#0000](https://github.com/scipian/rfcs/pull/3) - Community Issue: [scipian/community#6](https://github.com/scipian/community/issues/6) # Summary @@ -8,15 +8,14 @@ Scipian customer onboarding will allow a seamless process for customers to onboard to the Scipian platform. At a high level, this includes creation of -namespaces, RBAC rules, and importing Terraform state from a location external -to Scipian. +namespaces, RBAC rules, and distributing the authentication CLI. # Motivation [motivation]: #motivation -There is currently no process for a new customer to be onboarded to Scipian. Having -a smooth process in place will be paramount to onboarding multiple customers -who want to use Scipian. Having a low barrier of entry will encourage +There is currently no process for a new customer to be onboarded to Scipian. +Having a smooth process in place will be paramount to onboarding multiple +customers who want to use Scipian. Having a low barrier of entry will encourage teams to use Scipian. # Guide-level explanation @@ -24,7 +23,7 @@ teams to use Scipian. Scipian builds on and uses many Kubernetes primitives. Some of these include namespaces and RBAC rules. This allows multiple teams to use Scipian, while -keeping each team's data and interactions with Scipian separated from each other. +keeping each team's data and interactions with Scipian separated from eachother. For onboarding a new team to the Scipian platform, the following is created: @@ -37,10 +36,6 @@ Runs in Scipian. - **RoleBinding**. This will bind the created role to a set of users associated with the onboarding team. -If a team is already using Terraform to manage their infrastructure, Scipian -supports the importing of Terraform state from a location external to Scipian. -Scipian will pull this state and push it to it's own managed backend. - Below is the flow when onboarding a new customer to Scipian: - New customer requests to be onboarded to Scipian @@ -50,10 +45,6 @@ uses) of all the members who will need to use Scipian team - Onboarding team members will use the Scipian Authentication CLI to set up their kubeconfigs for interfacing Scipian. -- The onboarding team will create a Kubernetes secret in their namespace with -the AWS credentials needed for Scipian to pull Terraform state from an S3 bucket -- Scipian will pull that state into it's own backend -- Customer will then be onboarded and ready to use the Scipian platform # Reference-level explanation [reference-level-explanation]: #reference-level-explanation @@ -61,12 +52,8 @@ the AWS credentials needed for Scipian to pull Terraform state from an S3 bucket - RBAC rules and Namespace will be created manually by a Scipian admin using yaml and `kubectl`. This could be automated later via an onboarding UI, but that is beyond the scope of this RFC. -- Terraform state "puller" will be a Kubernetes job that runs a -special Docker container that will pull state from an S3 bucket, -and place in the appropriate workspace in Scipian's backend. This could be -initiated by a Scipian admin, or an onboarding user. The state puller will need -to map the current Terraform state workspace structure created by `scipctl` to -the new workspace structure that Scipian expects. +- The Scipian authentication CLI will need to be downloaded/installed by an +on-boarding customer. # Drawbacks [drawbacks]: #drawbacks @@ -79,9 +66,9 @@ identified by adding this feature. The onboarding outlined in this RFC will be an MVP level feature. Later, this functionality could be extended to include a self service UI, which would -automate RBAC rules and Namespace creation, as well as the pulling of extneral -Terraform state, thereby removing the requirement for a Scipian admin's direct -involvement every time a new customer wishes to onboard to Scipian. +automate RBAC rules and Namespace creation, thereby removing the requirement for +a Scipian admin's direct involvement every time a new customer wishes to onboard +to Scipian. # Prior art [prior-art]: #prior-art @@ -101,15 +88,10 @@ process over time. The following are open questions the Scipian dev community should answer before work commences: -- Should the Terraform state "puller", which will be a Kubernetes Job, be -initiated by the onboarding team, or by a Scipian admin? - Somewhat tied to this process is the question of how best to distribute the Scipian Authentication CLI to onboarding teams? - What areas do we need to consider to align us for future iterations and improvements to automate this process? -- Further research into Terraform will be needed, to determine the best way -to pull state and remap it into Scipian's backend in the correct workspace -structure expected by Scipian. # Future possibilities [future-possibilities]: #future-possibilities