Add latest changes from gitlab-org/gitlab@master

9 files changed, 154 insertions, 13 deletions

diff --git a/doc/api/members.md b/doc/api/members.md
index ccd8a8aaf61..4440b70c512 100644
--- a/doc/api/members.md
+++ b/doc/api/members.md
@@ -180,6 +180,7 @@ Example response:
   "web_url": "http://192.168.1.8:3000/root",
   "access_level": 30,
   "email": "john@example.com",
+  "created_at": "2012-10-22T14:13:35Z",
   "expires_at": null,
   "group_saml_identity": null
 }
diff --git a/doc/ci/cloud_deployment/index.md b/doc/ci/cloud_deployment/index.md
index 919d1439acb..b98e939e080 100644
--- a/doc/ci/cloud_deployment/index.md
+++ b/doc/ci/cloud_deployment/index.md
@@ -8,7 +8,10 @@ type: howto
 # Cloud deployment
 
 Interacting with a major cloud provider may have become a much needed task that's
-part of your delivery process. GitLab is making this process less painful by providing Docker images
+part of your delivery process. With GitLab you can
+[deploy your application anywhere](https://about.gitlab.com/stages-devops-lifecycle/deploy-targets/). 
+
+For some specific deployment targets, GitLab makes this process less painful by providing Docker images
 that come with the needed libraries and tools pre-installed.
 By referencing them in your CI/CD pipeline, you'll be able to interact with your chosen
 cloud provider more easily.
diff --git a/doc/development/geo/framework.md b/doc/development/geo/framework.md
index 7e59b56e684..55f4be07bb4 100644
--- a/doc/development/geo/framework.md
+++ b/doc/development/geo/framework.md
@@ -199,7 +199,7 @@ For example, to add support for files referenced by a `Widget` model with a
 
      # @param primary_key_in [Range, Widget] arg to pass to primary_key_in scope
      # @return [ActiveRecord::Relation<Widget>] everything that should be synced to this node, restricted by primary key
-     def self.replicables_for_geo_node(primary_key_in)
+     def self.replicables_for_current_secondary(primary_key_in)
        # Should be implemented. The idea of the method is to restrict
        # the set of synced items depending on synchronization settings
      end
diff --git a/doc/install/README.md b/doc/install/README.md
index fcfe4e32739..518b94d1694 100644
--- a/doc/install/README.md
+++ b/doc/install/README.md
@@ -89,6 +89,37 @@ the above methods, provided the cloud provider supports it.
 - _Testing only!_ [DigitalOcean and Docker Machine](digitaloceandocker.md):
   Quickly test any version of GitLab on DigitalOcean using Docker Machine.
 
-## Securing your GitLab installation
-
-After completing your installation, check out our [recommended practices to secure your GitLab instance](../security/README.md#securing-your-gitlab-installation).
+## Next steps
+
+Here are a few resources you might want to check out after completing the
+installation:
+
+- [Upload a license](../user/admin_area/license.md)  or [start a free trial](https://about.gitlab.com/free-trial/):
+  Activate all GitLab Enterprise Edition functionality with a license.
+- [Set up runners](https://docs.gitlab.com/runner/): Set up one or more GitLab
+  Runners, the agents that are responsible for all of GitLab's CI/CD features.
+- [GitLab Pages](../administration/pages/index.md): Configure GitLab Pages to
+  allow hosting of static sites.
+- [GitLab Registry](../administration/packages/container_registry.md): With the
+  GitLab Container Registry, every project can have its own space to store Docker
+  images.
+- [Secure GitLab](../security/README.md#securing-your-gitlab-installation):
+  Recommended practices to secure your GitLab instance.
+- [SMTP](https://docs.gitlab.com/omnibus/settings/smtp.html): Configure SMTP
+  for proper email notifications support.
+- [LDAP](../administration/auth/ldap/index.md): Configure LDAP to be used as
+  an authentication mechanism for GitLab.
+- [Back up and restore GitLab](../raketasks/backup_restore.md): Learn the different
+  ways you can back up or restore GitLab.
+- [Upgrade GitLab](../update/README.md): Every 22nd of the month, a new feature-rich GitLab version
+  is released. Learn how to upgrade to it, or to an interim release that contains a security fix.
+- [Scaling GitLab](../administration/reference_architectures/index.md):
+  GitLab supports several different types of clustering.
+- [Advanced Search](../integration/elasticsearch.md): Leverage Elasticsearch for
+  faster, more advanced code search across your entire GitLab instance.
+- [Geo replication](../administration/geo/index.md):
+  Geo is the solution for widely distributed development teams.
+- [Release and maintenance policy](../policy/maintenance.md): Learn about GitLab's
+  policies governing version naming, as well as release pace for major, minor, patch,
+  and security releases.
+- [Pricing](https://about.gitlab.com/pricing/): Pricing for the different tiers.
diff --git a/doc/security/two_factor_authentication.md b/doc/security/two_factor_authentication.md
index 0c2d616b003..995dea7809e 100644
--- a/doc/security/two_factor_authentication.md
+++ b/doc/security/two_factor_authentication.md
@@ -65,6 +65,8 @@ The following are important notes about 2FA:
   2FA enabled, 2FA is **not** required for those individually added members.
 - If there are multiple 2FA requirements (for example, group + all users, or multiple
   groups) the shortest grace period will be used.
+- It is possible to disallow subgroups from setting up their own 2FA requirements.
+  Navigate to the top-level group's **Settings > General > Permissions, LFS, 2FA > Two-factor authentication** and uncheck the **Allow subgroups to set up their own two-factor authentication rule** field. This action will cause all subgroups with 2FA requirements to stop requiring that from their members.
 
 ## Disabling 2FA for everyone
 
diff --git a/doc/user/application_security/sast/index.md b/doc/user/application_security/sast/index.md
index a33fccca3b3..455629829c0 100644
--- a/doc/user/application_security/sast/index.md
+++ b/doc/user/application_security/sast/index.md
@@ -201,6 +201,71 @@ spotbugs-sast:
     FAIL_NEVER: 1
 ```
 
+### Custom rulesets
+
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/235382) in GitLab 13.5.
+
+You can customize the default scanning rules provided with SAST's NodeJS-Scan and Gosec analyzers.
+Customization allows you to exclude rules and modify the behavior of existing rules.
+
+To customize the default scanning rules, create a file containing custom rules. These rules
+are passed through to the analyzer's underlying scanner tool.
+
+To create a custom ruleset:
+
+1. Create a `.gitlab` directory at the root of your project, if one doesn't already exist.
+1. Create a custom ruleset file named `sast-ruleset.toml` in the `.gitlab` directory.
+1. In the `sast-ruleset.toml` file, do one of the following:
+
+   - Define a custom analyzer configuration. In this example, customized rules are defined for the
+     `nodejs-scan` scanner:
+
+     ```toml
+     [nodejs-scan]
+       description = 'custom ruleset for nodejs-scan'
+
+       [[nodejs-scan.passthrough]]
+         type  = "raw"
+         value = '''
+     - nodejs-extensions:
+       - .js
+
+       template-extensions:
+       - .new
+       - .hbs
+       - ''
+
+       ignore-filenames:
+     - skip.js
+
+       ignore-paths:
+       - __MACOSX
+       - skip_dir
+       - node_modules
+
+       ignore-extensions:
+       - .hbs
+
+       ignore-rules:
+       - regex_injection_dos
+       - pug_jade_template
+       - express_xss
+
+     '''
+     ```
+
+   - Provide the name of the file containing a custom analyzer configuration. In this example,
+     customized rules for the `gosec` scanner are contained in the file `gosec-config.json`:
+
+     ```toml
+     [gosec]
+       description = 'custom ruleset for gosec'
+
+       [[gosec.passthrough]]
+         type  = "file"
+         value = "gosec-config.json"
+     ```
+
 ### Using environment variables to pass credentials for private repositories
 
 Some analyzers require downloading the project's dependencies in order to
diff --git a/doc/user/application_security/secret_detection/index.md b/doc/user/application_security/secret_detection/index.md
index 1204460bd75..bb10e9d7315 100644
--- a/doc/user/application_security/secret_detection/index.md
+++ b/doc/user/application_security/secret_detection/index.md
@@ -142,6 +142,49 @@ Secret Detection can be customized by defining available variables:
 | `SECRET_DETECTION_EXCLUDED_PATHS` | "" | Exclude vulnerabilities from output based on the paths. This is a comma-separated list of patterns. Patterns can be globs, or file or folder paths (for example, `doc,spec` ). Parent directories also match patterns. [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/225273) in GitLab 13.3. |
 | `SECRET_DETECTION_HISTORIC_SCAN` | false | Flag to enable a historic Gitleaks scan. |
 
+### Custom rulesets
+
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/211387) in GitLab 13.5.
+
+You can customize the default secret detection rules provided with GitLab.
+Customization allows you to exclude rules and add new rules.
+
+To create a custom ruleset:
+
+1. Create a `.gitlab` directory at the root of your project, if one doesn't already exist.
+1. Create a custom ruleset file named `secret-detection-ruleset.toml` in the `.gitlab` directory.
+1. In the `secret-detection-ruleset.toml` file, do one of the following:
+
+   - Define a custom ruleset:
+
+     ```toml
+     [secrets]
+       description = 'secrets custom rules configuration'
+
+       [[secrets.passthrough]]
+         type  = "raw"
+         target = "gitleaks.toml"
+         value = """\
+     title = "gitleaks config"
+     # add regexes to the regex table
+     [[rules]]
+     description = "Test for Raw Custom Rulesets"
+     regex = '''Custom Raw Ruleset T[est]{3}'''
+     """
+     ```
+
+   - Provide the name of the file containing a custom ruleset:
+
+     ```toml
+     [secrets]
+       description = 'secrets custom rules configuration'
+
+       [[secrets.passthrough]]
+         type  = "file"
+         target = "gitleaks.toml"
+         value = "config/gitleaks.toml"
+     ```
+
 ### Logging level
 
 To control the verbosity of logs set the `SECURE_LOG_LEVEL` environment variable. Messages of this logging level or higher are output. [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/10880) in GitLab 13.1.
diff --git a/doc/user/application_security/security_dashboard/index.md b/doc/user/application_security/security_dashboard/index.md
index f21f53e6895..ee42da24467 100644
--- a/doc/user/application_security/security_dashboard/index.md
+++ b/doc/user/application_security/security_dashboard/index.md
@@ -183,8 +183,8 @@ The fields in the export include:
 - Details
 - Additional Info
 - Severity
-- [CVE](https://cve.mitre.org/)
-- [CWE](https://cwe.mitre.org/)
+- [CVE](https://cve.mitre.org/) (Common Vulnerabilities and Exposures)
+- [CWE](https://cwe.mitre.org/) (Common Weakness Enumeration)
 - Other Identifiers
 
 ![Export vulnerabilities](img/instance_security_dashboard_export_csv_v13_4.png)
@@ -243,11 +243,7 @@ To create an issue associated with the vulnerability, click the **Create Issue**
 Once you create the issue, the linked issue icon in the vulnerability list:
 
 - Indicates that an issue has been created for that vulnerability.
-- Shows a tooltip that contains a link to the issue and an icon whose
-  color indicates the issue's status:
-
-  - Open issues: green
-  - Closed issues: blue
+- Shows a tooltip that contains a link to the issue.
 
 ![Display attached issues](img/vulnerability_list_table_v13_4.png)
 
diff --git a/doc/user/project/repository/x509_signed_commits/index.md b/doc/user/project/repository/x509_signed_commits/index.md
index 972a46ee7a3..9b420d84f50 100644
--- a/doc/user/project/repository/x509_signed_commits/index.md
+++ b/doc/user/project/repository/x509_signed_commits/index.md
@@ -26,7 +26,7 @@ For a commit or tag to be *verified* by GitLab:
   [Omnibus install custom public certificates](https://docs.gitlab.com/omnibus/settings/ssl.html#install-custom-public-certificates).
 - The signing time has to be within the time range of the [certificate validity](https://www.rfc-editor.org/rfc/rfc5280.html#section-4.1.2.5)
   which is usually up to three years.
-- The signing time is equal or later then commit time.
+- The signing time is equal or later than commit time.
 
 NOTE: **Note:**
 Certificate revocation lists are checked on a daily basis via background worker.