Add latest changes from gitlab-org/gitlab@master

.gitlab/ci/rules.gitlab-ci.yml

@@ -242,7 +242,7 @@
     - <<: *if-not-canonical-namespace
       when: never
     - changes: *ci-build-images-patterns
-    - changes: *code-backstage-qa-patterns
+    - changes: *code-qa-patterns
 
 ####################
 # Cache repo rules #

Gemfile

@@ -416,7 +416,7 @@ end
 gem 'octokit', '~> 4.15'
 
 # https://gitlab.com/gitlab-org/gitlab/issues/207207
-gem 'gitlab-mail_room', '~> 0.0.4', require: 'mail_room'
+gem 'gitlab-mail_room', '~> 0.0.6', require: 'mail_room'
 
 gem 'email_reply_trimmer', '~> 0.1'
 gem 'html2text'

Gemfile.lock

@@ -390,7 +390,7 @@ GEM
       opentracing (~> 0.4)
       redis (> 3.0.0, < 5.0.0)
     gitlab-license (1.0.0)
-    gitlab-mail_room (0.0.4)
+    gitlab-mail_room (0.0.6)
     gitlab-markup (1.7.1)
     gitlab-net-dns (0.9.1)
     gitlab-puma (4.3.3.gitlab.2)
@@ -1241,7 +1241,7 @@ DEPENDENCIES
   gitlab-chronic (~> 0.10.5)
   gitlab-labkit (= 0.12.0)
   gitlab-license (~> 1.0)
-  gitlab-mail_room (~> 0.0.4)
+  gitlab-mail_room (~> 0.0.6)
   gitlab-markup (~> 1.7.1)
   gitlab-net-dns (~> 0.9.1)
   gitlab-puma (~> 4.3.3.gitlab.2)

doc/development/integrations/secure.md

@@ -232,6 +232,34 @@ to colorize the messages they write to the Unix standard output and standard err
 We recommend using red to report errors, yellow for warnings, and green for notices.
 Also, we recommend prefixing error messages with `[ERRO]`, warnings with `[WARN]`, and notices with `[INFO]`.
 
+#### Logging level
+
+The scanner should filter out a log message if its log level is lower than the
+one set in the `SECURE_LOG_LEVEL` variable. For instance, `info` and `warn`
+messages should be skipped when `SECURE_LOG_LEVEL` is set to `error`. Accepted
+values are as follows, listed from highest to lowest:
+
+- `panic`
+- `fatal`
+- `error`
+- `warn`
+- `info`
+- `debug`
+- `trace`
+
+It is recommended to use the `debug` and `trace` levels for verbose logging
+that could be useful when debugging. The default value for `SECURE_LOG_LEVEL`
+should be set to `info`.
+
+#### common logutil package
+
+If you are using [go](https://golang.org/) and
+[common](https://gitlab.com/gitlab-org/security-products/analyzers/common),
+then it is suggested that you use [logrus](https://github.com/Sirupsen/logrus)
+and [common's logutil package](https://gitlab.com/gitlab-org/security-products/analyzers/common/-/tree/master/logutil)
+to configure the formatter for [logrus](https://github.com/Sirupsen/logrus).
+See the [logutil README.md](https://gitlab.com/gitlab-org/security-products/analyzers/common/-/tree/master/logutil/README.md)
+
 ## Report
 
 The report is a JSON document that combines vulnerabilities with possible remediations.

doc/user/application_security/container_scanning/index.md

@@ -174,6 +174,7 @@ using environment variables.
 | `CLAIR_DB_IMAGE_TAG`           | (**DEPRECATED - use `CLAIR_DB_IMAGE` instead**) The Docker image tag for the [PostgreSQL server hosting the vulnerabilities definitions](https://hub.docker.com/r/arminc/clair-db). It can be useful to override this value with a specific version, for example, to provide a consistent set of vulnerabilities for integration testing purposes.                                                                                                                                                                                                                                                                                                                                                                                                                                   | `latest`                                                                                                        |
 | `DOCKERFILE_PATH`              | The path to the `Dockerfile` to be used for generating remediations. By default, the scanner will look for a file named `Dockerfile` in the root directory of the project, so this variable should only be configured if your `Dockerfile` is in a non-standard location, such as a subdirectory. See [Solutions for vulnerabilities](#solutions-for-vulnerabilities-auto-remediation) for more details.                                                                                                                                                                                                                                                                                                                                                                          | `Dockerfile`                                                                                                    |
 | `ADDITIONAL_CA_CERT_BUNDLE`    | Bundle of CA certs that you want to trust. | "" |
+| `SECURE_LOG_LEVEL`             | The log levels available are: `panic`, `fatal`, `error`, `warn`, `info`, `debug`, `trace` | `info` |
 
 ### Overriding the Container Scanning template
 

doc/user/application_security/dependency_scanning/index.md

@@ -155,6 +155,7 @@ The following variables allow configuration of global dependency scanning settin
 | `DS_DISABLE_DIND`                       | Disable Docker-in-Docker and run analyzers [individually](#enabling-docker-in-docker). This variable is `true` by default. |
 | `ADDITIONAL_CA_CERT_BUNDLE`             | Bundle of CA certs to trust. |
 | `DS_EXCLUDED_PATHS`                     | Exclude vulnerabilities from output based on the paths. A comma-separated list of patterns. Patterns can be globs, or file or folder paths (for example, `doc,spec`). Parent directories also match patterns. Default: `"spec, test, tests, tmp"` |
+| `SECURE_LOG_LEVEL`                      | Default log level is `info`, you can set it to any of the following strings: `panic`, `fatal`, `error`, `warn`, `info`, `debug`, `trace`. |
 
 #### Configuring Docker-in-Docker orchestrator
 

doc/user/application_security/sast/index.md

@@ -285,6 +285,18 @@ See [Analyzer settings](#analyzer-settings) for the complete list of available o
 
 SAST can be [configured](#customizing-the-sast-settings) using environment variables.
 
+#### Logging Level
+
+You can control the verbosity of logs by setting the `SECURE_LOG_LEVEL` env var. It's default is set to `info`, you can set it to any of the following levels:
+
+- `panic`
+- `fatal`
+- `error`
+- `warn`
+- `info`
+- `debug`
+- `trace`
+
 #### Custom Certificate Authority
 
 To trust a custom Certificate Authority, set the `ADDITIONAL_CA_CERT_BUNDLE` variable to the bundle

doc/user/application_security/secret_detection/index.md

@@ -146,6 +146,18 @@ Secret Detection can be customized by defining available variables:
 | `SECRET_DETECTION_COMMIT_TO` | -       | The commit a Gitleaks scan ends at. |
 | `SECRET_DETECTION_HISTORIC_SCAN` | false | Flag to enable a historic Gitleaks scan. |
 
+### Logging Level
+
+You can control the verbosity of logs by setting the `SECURE_LOG_LEVEL` env var. It's default is set to `info`, you can set it to any of the following levels:
+
+- `panic`
+- `fatal`
+- `error`
+- `warn`
+- `info`
+- `debug`
+- `trace`
+
 ## Full History Secret Scan
 
 GitLab 12.11 introduced support for scanning the full history of a repository. This new functionality

doc/user/application_security/security_dashboard/index.md

@@ -200,6 +200,19 @@ When using [Auto DevOps](../../../topics/autodevops/index.md), use
 [special environment variables](../../../topics/autodevops/customize.md#environment-variables)
 to configure daily security scans.
 
+## Vulnerability list
+
+Each dashboard's vulnerability list contains new vulnerabilities discovered in the latest scans.
+Click any vulnerability in the table to see more information on that vulnerability. To create an
+issue associated with the vulnerability, click the **Create Issue** button.
+
+![Create an issue for the vulnerability](img/standalone_vulnerability_page_v13_1.png)
+
+Once you create the issue, the vulnerability list contains a link to the issue and an icon whose
+color indicates the issue's status (green for open issues, blue for closed issues).
+
+![Display attached issues](img/vulnerability_list_table_v13_1.png)
+
 <!-- ## Troubleshooting
 
 Include any troubleshooting steps that you can foresee. If you know beforehand what issues

doc/user/clusters/applications.md

@@ -1331,6 +1331,43 @@ by running the following command:
 kubectl delete -f https://gitlab.com/gitlab-org/cluster-integration/cluster-applications/-/raw/02c8231e30ef5b6725e6ba368bc63863ceb3c07d/src/default-data/knative/istio-metrics.yaml
 ```
 
+### Install AppArmor using GitLab CI/CD
+
+> [Introduced](https://gitlab.com/gitlab-org/cluster-integration/cluster-applications/-/merge_requests/100) in GitLab 13.1.
+
+To install AppArmor into the `gitlab-managed-apps` namespace of your cluster using GitLab CI/CD, define the following configuration in `.gitlab/managed-apps/config.yaml`:
+
+```yaml
+apparmor:
+  installed: true
+```
+
+You can define one or more AppArmor profiles by adding them into `.gitlab/managed-apps/apparmor/values.yaml` as the following:
+
+```yaml
+profiles:
+  profile-one: |-
+    profile profile-one {
+      file,
+    }
+```
+
+Refer to the [AppArmor chart](https://gitlab.com/gitlab-org/charts/apparmor) for more information on this chart.
+
+#### Using AppArmor profiles in your deployments
+
+After installing AppAmor, you can use profiles by adding Pod Annotations. If you're using Auto
+DevOps, you can [customize `auto-deploy-values.yaml`](../../topics/autodevops/customize.md#customize-values-for-helm-chart)
+to annotate your pods. Although it's helpful to be aware of the [list of custom attributes](https://gitlab.com/gitlab-org/charts/auto-deploy-app#gitlabs-auto-deploy-helm-chart), you're only required to set
+`podAnnotations` as follows:
+
+```yaml
+podAnnotations:
+  container.apparmor.security.beta.kubernetes.io/auto-deploy-app: localhost/profile-one
+```
+
+The only information to be changed here is the profile name which is `profile-one` in this example. Refer to the [AppArmor tutorial](https://kubernetes.io/docs/tutorials/clusters/apparmor/#securing-a-pod) for more information on how AppArmor is integrated in Kubernetes.
+
 ## Upgrading applications
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/24789) in GitLab 11.8.

spec/routing/project_routing_spec.rb

@@ -778,6 +778,12 @@ describe 'project routing' do
     end
   end
 
+  describe Projects::Settings::OperationsController, 'routing' do
+    it 'to #reset_alerting_token' do
+      expect(post('/gitlab/gitlabhq/-/settings/operations/reset_alerting_token')).to route_to('projects/settings/operations#reset_alerting_token', namespace_id: 'gitlab', project_id: 'gitlabhq')
+    end
+  end
+
   describe Projects::Settings::RepositoryController, 'routing' do
     it 'to #show' do
       expect(get('/gitlab/gitlabhq/-/settings/repository')).to route_to('projects/settings/repository#show', namespace_id: 'gitlab', project_id: 'gitlabhq')