diff options
Diffstat (limited to 'doc/architecture/blueprints/remote_development/index.md')
| -rw-r--r-- | doc/architecture/blueprints/remote_development/index.md | 49 |
1 files changed, 32 insertions, 17 deletions
diff --git a/doc/architecture/blueprints/remote_development/index.md b/doc/architecture/blueprints/remote_development/index.md index c7d1ec29add..d64fbfc8b55 100644 --- a/doc/architecture/blueprints/remote_development/index.md +++ b/doc/architecture/blueprints/remote_development/index.md @@ -485,7 +485,11 @@ RestartRequested -left-> Running : status=Running ## Injecting environment variables and files into a workspace -Like CI, there is a need to inject environment variables and files into a workspace. These environment variables and files will be frozen in time during workspace creation to ensure the same values are injected into the workspace every time it starts/restarts. Thus, a new database table, on the lines of `ci_job_variables` will be required. This table will contain the following columns - +Like CI, there is a need to inject environment variables and files into a workspace. +These environment variables and files will be frozen in time during workspace creation to ensure the same values +are injected into the workspace every time it starts/restarts. +Thus, a new database table, on the lines of `ci_job_variables` will be required. +This table will contain the following columns - - `key` - To store the name of the environment variable or the file. - `encrypted_value` - To store the encrypted value of the environment variable or the file. @@ -493,29 +497,40 @@ Like CI, there is a need to inject environment variables and files into a worksp - `workspace_id` - To reference the workspace the environment variable or the file is to be injected into. - `variable_type` - To store whether this data is to be injected as an environment variable or a file. -To perform the encryption, a secret key would be required. This would be uniquely generated for each workpsace upon creation. -Having a unique secret key which is used for encrypting the corresponding workspace's environment variable and file data in the workspace, improves the security profile. +To perform the encryption, the GitLab instance level secret key is used. The data about the environment variables +and files will only be sent to the Agent when required i.e. -Because of the nature of reconciliation loop between Agent and Rails, it is not scalable to decrypt these values at Rails side for each request. -Instead, the `key`, `encrypted_value` and `encrypted_value_iv` of each environment variable of the workspace are sent to the Agent along with the workspace's `secret_key` -for the Agent to decrypt them in place. +- When new workspace creation request has been received from the user and an Agent initiates a Partial Reconciliation request +- When an Agent initiates a Full Reconciliation request -To optimize this further, the data about the environment variables and files along with the secret key will only be sent when required i.e. +More details about the implementation details can be found in this [epic](https://gitlab.com/groups/gitlab-org/-/epics/10882). -- When new workspace creation request has been received from the user and an Agent initiates a Partial Reonciliation request -- When an Agent initiates a Full Reconciliation request +We need to keep in mind potential performance concerns of decrypting workspace variables on the Rails side, +and perform benchmarks of what scale we will reach unacceptably long request times for a reconcile request. -When a workspace is created from a project, it will inherit all the variables from the group/subgroup/project hierarchy which are defined under -[`Settings > CI/CD > Variables`](../../../ci/variables/index.md#define-a-cicd-variable-in-the-ui). This aspect will be generalized to allow for defining `Variables` -which will be inherited in both CI/CD and Workspaces. +e.g. a reconcile request for 100 workspaces with 20 encrypted values each == 2000 decryptions in a single request. -A user will also be able to define, at a user level, environment variables and files to be injected into each workspace created by them. +More details about the benchmarking can be found in this [issue](https://gitlab.com/gitlab-org/gitlab/-/issues/421504). -When a new workspace is created, a new personal access token associated to the user who created the workspace will be generated. -This personal access token will be tied to the lifecycle of the workspace and will be injected into the workspace as an environment variable or a file -to allow for cloning private projects and supporting transparent Git operations from within the workspace out-of-the-box among other things. +When a workspace is created from a project, it will inherit all the variables from the group/subgroup/project hierarchy +which are defined under [`Settings > CI/CD > Variables`](../../../ci/variables/index.md#define-a-cicd-variable-in-the-ui). +This aspect will be generalized to allow for defining `Variables` which will be inherited in both CI/CD and Workspaces. +A user will also be able to define, at a user level, environment variables and files to be injected into each +workspace created by them. While creating a workspace, a user would be able to override any environment variable +or file that is inherited from the group/subgroup/project/user hierarchy. -More details about the implementation details can be found in this [epic](https://gitlab.com/groups/gitlab-org/-/epics/10882). +## Git operations from within a workspace + +When a new workspace is created, a new personal access token associated to the user who created the workspace +will be generated. This personal access token will be tied to the lifecycle of the workspace and will be injected +into the workspace as a file to allow for cloning private projects and supporting transparent Git operations from +within the workspace out-of-the-box among other things using a +[custom Git credential helper](https://git-scm.com/book/en/v2/Git-Tools-Credential-Storage). + +[Investigation](https://gitlab.com/gitlab-org/gitlab/-/issues/421289#note_1511631931) into using +ephemeral tokens(JWTs/OAuth/OIDC/etc.) instead of Personal Access Tokens revealed the need to have a common +JWT Authentication/Authorization layer at GitLab which can be tracked in this [issue](https://gitlab.com/gitlab-org/gitlab/-/issues/421983). +Once such a feature is available, Personal Access Tokens for each workspace would be replaced with JWT tokens. ## Workspace user traffic authentication and authorization |