From 52f64f9b67c6618dd1d300ae8043cfbb3f752ebe Mon Sep 17 00:00:00 2001 From: Jocelyn Eillis Date: Wed, 29 May 2024 03:35:18 +0000 Subject: [PATCH 1/9] Add new file --- ...ict-user-defined-variables-deprecation.yml | 69 +++++++++++++++++++ 1 file changed, 69 insertions(+) create mode 100644 data/deprecations/17-1-restrict-user-defined-variables-deprecation.yml diff --git a/data/deprecations/17-1-restrict-user-defined-variables-deprecation.yml b/data/deprecations/17-1-restrict-user-defined-variables-deprecation.yml new file mode 100644 index 00000000000000..728e3cbf8115f3 --- /dev/null +++ b/data/deprecations/17-1-restrict-user-defined-variables-deprecation.yml @@ -0,0 +1,69 @@ +# Use this template to announce a feature deprecation or other +# important planned changes at least three releases prior to removal. +# Breaking changes must happen in a major release. +# +# Copy this template into a new file in /data/deprecations, and name the file similar to: +# `16-9-deprecated-feature.yml`, where `16-9` is the announcement milestone, +# not the removal milestone. +# +# See the deprecation guidelines to confirm your understanding of GitLab's definitions: +# https://docs.gitlab.com/ee/development/deprecation_guidelines/#terminology +# +# If an End of Support period applies, see the OPTIONAL section below. +# +# For more information, see the handbook: +# https://handbook.gitlab.com/handbook/marketing/blog/release-posts/#deprecations-and-other-planned-breaking-change-announcements + +# =================== +# REQUIRED FIELDS +# =================== + +# ----- DELETE EVERYTHING ABOVE THIS LINE ----- + +- title: "Feature A is deprecated" + # The milestones for the deprecation announcement, and the removal. + removal_milestone: "XX.YY" + announcement_milestone: "XX.YY" + # Change breaking_change to false if needed. + breaking_change: true + # The stage and GitLab username of the person reporting the change, + # and a link to the deprecation issue + reporter: exampleuser + stage: stage + issue_url: https://gitlab.com/gitlab-org/gitlab/-/issues/000000 + impact: # Can be one of: [critical, high, medium, low] + scope: # Can be one or a combination of: [instance, group, project] + resolution_role: # Can be one of: [Admin, Owner, Maintainer, Developer] + manual_task: # Can be true or false. Use this to denote whether a resolution action must be performed manually (true), or if it can be automated by using the API or other automation (false). + body: | # (required) Don't change this line. + + +# ============================== +# OPTIONAL END-OF-SUPPORT FIELDS +# ============================== +# +# If an End of Support period applies: +# 1) Share this announcement in the `#spt_managers` Support channel in Slack +# 2) Mention `@gitlab-com/support` in this merge request. +# + # When support for this feature ends, in XX.YY milestone format. + end_of_support_milestone: + # Array of tiers the feature is currently available to, + # like [Free, Silver, Gold, Core, Premium, Ultimate] + tiers: + # Links to documentation and thumbnail image + documentation_url: + image_url: + # Use the youtube thumbnail URL with the structure of https://img.youtube.com/vi/UNIQUEID/hqdefault.jpg + video_url: -- GitLab From 9b7563a8b23d1bb527147fb4f310b8717d614394 Mon Sep 17 00:00:00 2001 From: Jocelyn Eillis Date: Sat, 27 Jul 2024 19:31:48 +0000 Subject: [PATCH 2/9] Initial deprecation notice draft --- ...ict-user-defined-variables-deprecation.yml | 40 +++++-------------- 1 file changed, 10 insertions(+), 30 deletions(-) diff --git a/data/deprecations/17-1-restrict-user-defined-variables-deprecation.yml b/data/deprecations/17-1-restrict-user-defined-variables-deprecation.yml index 728e3cbf8115f3..8e0a88a9b984e4 100644 --- a/data/deprecations/17-1-restrict-user-defined-variables-deprecation.yml +++ b/data/deprecations/17-1-restrict-user-defined-variables-deprecation.yml @@ -1,40 +1,20 @@ -# Use this template to announce a feature deprecation or other -# important planned changes at least three releases prior to removal. -# Breaking changes must happen in a major release. -# -# Copy this template into a new file in /data/deprecations, and name the file similar to: -# `16-9-deprecated-feature.yml`, where `16-9` is the announcement milestone, -# not the removal milestone. -# -# See the deprecation guidelines to confirm your understanding of GitLab's definitions: -# https://docs.gitlab.com/ee/development/deprecation_guidelines/#terminology -# -# If an End of Support period applies, see the OPTIONAL section below. -# -# For more information, see the handbook: -# https://handbook.gitlab.com/handbook/marketing/blog/release-posts/#deprecations-and-other-planned-breaking-change-announcements - -# =================== -# REQUIRED FIELDS -# =================== - # ----- DELETE EVERYTHING ABOVE THIS LINE ----- -- title: "Feature A is deprecated" +- title: "`restrict_user_defined_variables` boolean is deprecated" # The milestones for the deprecation announcement, and the removal. - removal_milestone: "XX.YY" - announcement_milestone: "XX.YY" + removal_milestone: "19.0" + announcement_milestone: "17.3" # Change breaking_change to false if needed. breaking_change: true # The stage and GitLab username of the person reporting the change, # and a link to the deprecation issue - reporter: exampleuser - stage: stage - issue_url: https://gitlab.com/gitlab-org/gitlab/-/issues/000000 - impact: # Can be one of: [critical, high, medium, low] - scope: # Can be one or a combination of: [instance, group, project] - resolution_role: # Can be one of: [Admin, Owner, Maintainer, Developer] - manual_task: # Can be true or false. Use this to denote whether a resolution action must be performed manually (true), or if it can be automated by using the API or other automation (false). + reporter: jocelynjane + stage: verify + issue_url: https://gitlab.com/gitlab-org/gitlab/-/issues/440338 + impact: low # Can be one of: [critical, high, medium, low] + scope: [instance, group, project] # Can be one or a combination of: [instance, group, project] + resolution_role: [Admin, Owner, Maintainer, Developer] # Can be one of: [Admin, Owner, Maintainer, Developer] + manual_task: false # Can be true or false. Use this to denote whether a resolution action must be performed manually (true), or if it can be automated by using the API or other automation (false). body: | # (required) Don't change this line. + + GitLab believes in secure-by-default practices. To honor this, we are making some changes to support least privilege principles across the way environment variables work. Today, user permission restrictions defaults are set to false, which means that users with the developer role or higher are able to pass pipeline variables without any verification or opt-in. In 18.0, GitLab is updating the restrict_user_defined_variables default to true. As a result of this change, your project environment variables will be less permissive by default, and require a manual update to change the user permissions that can pass variables. + + To enable a more secure-by-default experience for passing pipeline variables, the setting can be opted-in to before 18.0 starting in 17.7. For more information on how to update this setting see our [documentation](https://docs.gitlab.com/ee/ci/variables/#restrict-pipeline-variables). # ============================== # OPTIONAL END-OF-SUPPORT FIELDS -- GitLab From ba0ea8221ff812d7d042021ca1be25101e7c13d0 Mon Sep 17 00:00:00 2001 From: Jackie Porter Date: Mon, 11 Nov 2024 15:03:46 +0000 Subject: [PATCH 4/9] Apply 1 suggestion(s) to 1 file(s) --- .../17-1-restrict-user-defined-variables-deprecation.yml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/data/deprecations/17-1-restrict-user-defined-variables-deprecation.yml b/data/deprecations/17-1-restrict-user-defined-variables-deprecation.yml index 420040dcaf26b1..a9db2a8ee71afa 100644 --- a/data/deprecations/17-1-restrict-user-defined-variables-deprecation.yml +++ b/data/deprecations/17-1-restrict-user-defined-variables-deprecation.yml @@ -5,7 +5,7 @@ removal_milestone: "18.0" announcement_milestone: "17.3" # Change breaking_change to false if needed. - breaking_change: true + breaking_change: false # The stage and GitLab username of the person reporting the change, # and a link to the deprecation issue reporter: jreporter -- GitLab From 2ae57df552e1e04444eed06a9e2fa4ba9fd46b87 Mon Sep 17 00:00:00 2001 From: Jackie Porter Date: Thu, 14 Nov 2024 14:38:19 +0000 Subject: [PATCH 5/9] Apply 1 suggestion(s) to 1 file(s) Co-authored-by: Marcel Amirault --- .../17-1-restrict-user-defined-variables-deprecation.yml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/data/deprecations/17-1-restrict-user-defined-variables-deprecation.yml b/data/deprecations/17-1-restrict-user-defined-variables-deprecation.yml index a9db2a8ee71afa..79ee2bc7b37d14 100644 --- a/data/deprecations/17-1-restrict-user-defined-variables-deprecation.yml +++ b/data/deprecations/17-1-restrict-user-defined-variables-deprecation.yml @@ -19,7 +19,7 @@ GitLab believes in secure-by-default practices. To honor this, we are making some changes to support least privilege principles across the way environment variables work. Today, user permission restrictions defaults are set to false, which means that users with the developer role or higher are able to pass pipeline variables without any verification or opt-in. In 18.0, GitLab is updating the restrict_user_defined_variables default to true. As a result of this change, your project environment variables will be less permissive by default, and require a manual update to change the user permissions that can pass variables. - To enable a more secure-by-default experience for passing pipeline variables, the setting can be opted-in to before 18.0 starting in 17.7. For more information on how to update this setting see our [documentation](https://docs.gitlab.com/ee/ci/variables/#restrict-pipeline-variables). + You can already start using a more secure-by-default experience for pipeline variables by enabling the current setting with the Project settings API, to increase the allowed role to Maintainers and above. You can also raise the minimum role to the recommended [Owner only, or no one](https://docs.gitlab.com/ee/ci/variables/#set-a-minimum-role-for-pipeline-variables). Starting in 17.7, this will be the default for all new projects, but we plan to make this easier to manage by adding an option to control this from the project settings UI. # ============================== # OPTIONAL END-OF-SUPPORT FIELDS -- GitLab From c8951a5398246cf40c5de5fdf746d7785e9f29af Mon Sep 17 00:00:00 2001 From: Jackie Porter Date: Thu, 14 Nov 2024 14:38:26 +0000 Subject: [PATCH 6/9] Apply 1 suggestion(s) to 1 file(s) Co-authored-by: Marcel Amirault --- .../17-1-restrict-user-defined-variables-deprecation.yml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/data/deprecations/17-1-restrict-user-defined-variables-deprecation.yml b/data/deprecations/17-1-restrict-user-defined-variables-deprecation.yml index 79ee2bc7b37d14..c3c52fbdef8966 100644 --- a/data/deprecations/17-1-restrict-user-defined-variables-deprecation.yml +++ b/data/deprecations/17-1-restrict-user-defined-variables-deprecation.yml @@ -17,7 +17,7 @@ manual_task: false # Can be true or false. Use this to denote whether a resolution action must be performed manually (true), or if it can be automated by using the API or other automation (false). body: | # (required) Don't change this line. - GitLab believes in secure-by-default practices. To honor this, we are making some changes to support least privilege principles across the way environment variables work. Today, user permission restrictions defaults are set to false, which means that users with the developer role or higher are able to pass pipeline variables without any verification or opt-in. In 18.0, GitLab is updating the restrict_user_defined_variables default to true. As a result of this change, your project environment variables will be less permissive by default, and require a manual update to change the user permissions that can pass variables. + GitLab believes in secure-by-default practices. To honor this, we are making some changes to support least privilege principles relating to the use of CI/CD variables. Today, users with the Developer role or higher are able to use [pipeline variables](https://docs.gitlab.com/ee/ci/variables/#use-pipeline-variables) by default, without any verification or opt-in. In 18.0, GitLab is updating the [pipeline variable restrictions](https://docs.gitlab.com/ee/ci/variables/#restrict-pipeline-variables) to default enabled. As a result of this change, your project's use of pipeline CI/CD variables will be stricter by default, increased to only users with the Owner role. If necessary, you can manually set this setting to a lower role if still needed for your workflows, though it's not recommended. You can already start using a more secure-by-default experience for pipeline variables by enabling the current setting with the Project settings API, to increase the allowed role to Maintainers and above. You can also raise the minimum role to the recommended [Owner only, or no one](https://docs.gitlab.com/ee/ci/variables/#set-a-minimum-role-for-pipeline-variables). Starting in 17.7, this will be the default for all new projects, but we plan to make this easier to manage by adding an option to control this from the project settings UI. -- GitLab From c6cb673275018212e8b7578d9c06186342549152 Mon Sep 17 00:00:00 2001 From: Jackie Porter Date: Thu, 14 Nov 2024 14:38:48 +0000 Subject: [PATCH 7/9] Apply 1 suggestion(s) to 1 file(s) Co-authored-by: Marcel Amirault --- .../17-1-restrict-user-defined-variables-deprecation.yml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/data/deprecations/17-1-restrict-user-defined-variables-deprecation.yml b/data/deprecations/17-1-restrict-user-defined-variables-deprecation.yml index c3c52fbdef8966..156ac6da2a1654 100644 --- a/data/deprecations/17-1-restrict-user-defined-variables-deprecation.yml +++ b/data/deprecations/17-1-restrict-user-defined-variables-deprecation.yml @@ -1,6 +1,6 @@ # ----- DELETE EVERYTHING ABOVE THIS LINE ----- -- title: "Updated default for `restrict_user_defined_variables`" +- title: "Increased default security for use of pipeline variables" # The milestones for the deprecation announcement, and the removal. removal_milestone: "18.0" announcement_milestone: "17.3" -- GitLab From 291c6af2fc83487a2324d71db523de51f9505fc7 Mon Sep 17 00:00:00 2001 From: Marcel Amirault Date: Wed, 20 Nov 2024 06:38:44 +0000 Subject: [PATCH 8/9] Apply 1 suggestion(s) to 1 file(s) --- .../17-1-restrict-user-defined-variables-deprecation.yml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/data/deprecations/17-1-restrict-user-defined-variables-deprecation.yml b/data/deprecations/17-1-restrict-user-defined-variables-deprecation.yml index 156ac6da2a1654..686355eacb6d51 100644 --- a/data/deprecations/17-1-restrict-user-defined-variables-deprecation.yml +++ b/data/deprecations/17-1-restrict-user-defined-variables-deprecation.yml @@ -19,7 +19,7 @@ GitLab believes in secure-by-default practices. To honor this, we are making some changes to support least privilege principles relating to the use of CI/CD variables. Today, users with the Developer role or higher are able to use [pipeline variables](https://docs.gitlab.com/ee/ci/variables/#use-pipeline-variables) by default, without any verification or opt-in. In 18.0, GitLab is updating the [pipeline variable restrictions](https://docs.gitlab.com/ee/ci/variables/#restrict-pipeline-variables) to default enabled. As a result of this change, your project's use of pipeline CI/CD variables will be stricter by default, increased to only users with the Owner role. If necessary, you can manually set this setting to a lower role if still needed for your workflows, though it's not recommended. - You can already start using a more secure-by-default experience for pipeline variables by enabling the current setting with the Project settings API, to increase the allowed role to Maintainers and above. You can also raise the minimum role to the recommended [Owner only, or no one](https://docs.gitlab.com/ee/ci/variables/#set-a-minimum-role-for-pipeline-variables). Starting in 17.7, this will be the default for all new projects, but we plan to make this easier to manage by adding an option to control this from the project settings UI. + You can already start using a more secure-by-default experience for pipeline variables by enabling the current setting with the Project settings API, to increase the allowed role to Maintainers and above. You can also raise the minimum role to the recommended [Owner only, or no one](https://docs.gitlab.com/ee/ci/variables/#set-a-minimum-role-for-pipeline-variables). Starting in 17.7, this will be the default for all new projects for self-managed instances, and the default for all new projects in new namespaces on GitLab.com. We also plan to make this easier to manage by adding an option to control this from the project settings UI. # ============================== # OPTIONAL END-OF-SUPPORT FIELDS -- GitLab From ef24e56f0ae17162b8182a0a38ac828a7fef5ea5 Mon Sep 17 00:00:00 2001 From: Marcel Amirault Date: Wed, 20 Nov 2024 15:53:20 +0900 Subject: [PATCH 9/9] Rebuild deprecations doc --- ...rict-user-defined-variables-deprecation.yml | 11 +++++------ doc/update/deprecations.md | 18 ++++++++++++++++++ 2 files changed, 23 insertions(+), 6 deletions(-) diff --git a/data/deprecations/17-1-restrict-user-defined-variables-deprecation.yml b/data/deprecations/17-1-restrict-user-defined-variables-deprecation.yml index 686355eacb6d51..1ff4d99f3af8b2 100644 --- a/data/deprecations/17-1-restrict-user-defined-variables-deprecation.yml +++ b/data/deprecations/17-1-restrict-user-defined-variables-deprecation.yml @@ -3,7 +3,7 @@ - title: "Increased default security for use of pipeline variables" # The milestones for the deprecation announcement, and the removal. removal_milestone: "18.0" - announcement_milestone: "17.3" + announcement_milestone: "17.7" # Change breaking_change to false if needed. breaking_change: false # The stage and GitLab username of the person reporting the change, @@ -12,13 +12,12 @@ stage: verify issue_url: https://gitlab.com/gitlab-org/gitlab/-/issues/502382 impact: medium # Can be one of: [critical, high, medium, low] - scope: [project] # Can be one or a combination of: [instance, group, project] - resolution_role: [Maintainer] # Can be one of: [Admin, Owner, Maintainer, Developer] - manual_task: false # Can be true or false. Use this to denote whether a resolution action must be performed manually (true), or if it can be automated by using the API or other automation (false). + scope: [project] # Can be one or a combination of: [instance, group, project] + resolution_role: [Maintainer] # Can be one of: [Admin, Owner, Maintainer, Developer] + manual_task: false # Can be true or false. Use this to denote whether a resolution action must be performed manually (true), or if it can be automated by using the API or other automation (false). body: | # (required) Don't change this line. - GitLab believes in secure-by-default practices. To honor this, we are making some changes to support least privilege principles relating to the use of CI/CD variables. Today, users with the Developer role or higher are able to use [pipeline variables](https://docs.gitlab.com/ee/ci/variables/#use-pipeline-variables) by default, without any verification or opt-in. In 18.0, GitLab is updating the [pipeline variable restrictions](https://docs.gitlab.com/ee/ci/variables/#restrict-pipeline-variables) to default enabled. As a result of this change, your project's use of pipeline CI/CD variables will be stricter by default, increased to only users with the Owner role. If necessary, you can manually set this setting to a lower role if still needed for your workflows, though it's not recommended. - + You can already start using a more secure-by-default experience for pipeline variables by enabling the current setting with the Project settings API, to increase the allowed role to Maintainers and above. You can also raise the minimum role to the recommended [Owner only, or no one](https://docs.gitlab.com/ee/ci/variables/#set-a-minimum-role-for-pipeline-variables). Starting in 17.7, this will be the default for all new projects for self-managed instances, and the default for all new projects in new namespaces on GitLab.com. We also plan to make this easier to manage by adding an option to control this from the project settings UI. # ============================== diff --git a/doc/update/deprecations.md b/doc/update/deprecations.md index 3ab0c71fe82d74..a90819efc9f2e9 100644 --- a/doc/update/deprecations.md +++ b/doc/update/deprecations.md @@ -489,6 +489,24 @@ Project Owners and Maintainers should review their private projects' lists of me +
+ +### Increased default security for use of pipeline variables + +
+ +- Announced in GitLab 17.7 +- Removal in GitLab 18.0 +- To discuss this change or learn more, see the [deprecation issue](https://gitlab.com/gitlab-org/gitlab/-/issues/502382). + +
+ +GitLab believes in secure-by-default practices. To honor this, we are making some changes to support least privilege principles relating to the use of CI/CD variables. Today, users with the Developer role or higher are able to use [pipeline variables](https://docs.gitlab.com/ee/ci/variables/#use-pipeline-variables) by default, without any verification or opt-in. In 18.0, GitLab is updating the [pipeline variable restrictions](https://docs.gitlab.com/ee/ci/variables/#restrict-pipeline-variables) to default enabled. As a result of this change, your project's use of pipeline CI/CD variables will be stricter by default, increased to only users with the Owner role. If necessary, you can manually set this setting to a lower role if still needed for your workflows, though it's not recommended. + +You can already start using a more secure-by-default experience for pipeline variables by enabling the current setting with the Project settings API, to increase the allowed role to Maintainers and above. You can also raise the minimum role to the recommended [Owner only, or no one](https://docs.gitlab.com/ee/ci/variables/#set-a-minimum-role-for-pipeline-variables). Starting in 17.7, this will be the default for all new projects for self-managed instances, and the default for all new projects in new namespaces on GitLab.com. We also plan to make this easier to manage by adding an option to control this from the project settings UI. + +
+
### Limited `scan` actions in a scan execution policy -- GitLab