GitLab 11.5 released with Group Security and Operations Dashboards, and Access Control for Pages
GitLab 11.5 released with Group Security and Operations Dashboards, Access Control for GitLab Pages, Knative for Kubernetes, and much more!
Group dashboard for security teams
For a long time, developers have used GitLab as a tool to secure their code. But now,
GitLab is making security teams first-class citizens so they can use GitLab to effect better application security and ensure compliance. With 11.5, the
Group Security Dashboard pulls together all of the information security personnel need into one place, so folks like CISOs,
CIOs, and application security leaders get a specific view designed for them.
The group dashboard has a redesigned look and new visualizations, bringing together
security information across multiple projects and providing a high-level view while
also enabling the ability to drill down into specific reports. With 11.5, we're
starting with SAST reports, and we'll be adding more to the group dashboard in
the future. Our goal is to build a single tool that security teams can use
instead of needing to switch back and forth between multiple tools.
New dashboard for operations teams
In the same way that the Group Security Dashboard makes security teams first-class citizens, the Operations Dashboard provides a
tailored experience for operations professionals. This instance-wide dashboard
provides a single view across projects to get a summary of each project’s
operational health, including pipeline and alert status.
Control access to GitLab Pages
GitLab Pages is an easy way to
serve static content on the web, making it perfect for use cases such as
documentation for your project. But what about private projects where
documentation and other static artifacts should only be accessed by project
members? In the past, you'd either have to make your assets public to take
advantage of Pages, or you would not be able to use the feature at all.
Now, in GitLab 11.5, the same access control permissions that apply to your
issues and code can also be applied to static webpages served by GitLab Pages.
Unauthenticated users will get a 404 when visiting the link. As of today,
access controls for GitLab pages is available for self-managed GitLab,
with GitLab.com support coming soon.
“Serverless” is a popular, yet often misunderstood industry term. Some folks equate
serverless with "Function as a Service," or FaaS, but this isn't quite accurate. In a nutshell, serverless enables a programming paradigm where you are able
to focus on writing business logic without having to understand or even
worry about the underlying infrastructure where your software is deployed.
As such, both functions and applications can be serverless.
Today, Knative is still in alpha, but there are some compelling reasons to deploy applications using Knative as it comes with some powerful functionality out-of-the-box. In particular, Knative manages pod scaling for you so you can automatically scale up, or even scale down to zero without additional configuration. Additionally, Knative comes with eventing built in so using it to deploy microservices makes it easier to manage inter-process communication between your producer and consumer services.
Tuomo did an amazing job by implementing Access control for Pages, a highly requested feature.
Private projects can now restrict access to their content to authorized users. This enables groups of
people to host internal web pages that may contain sensitive information, for example.
Security teams need to easily access information about the security status of all their projects,
so they know which is the most important task to take next. This is even more important for Directors
of Security that need to have a high-level view of possible critical issues affecting the
entire development.
With GitLab 11.5, a first iteration of a new Security Dashboard is available at group level. It
provides a summary for all the SAST
vulnerabilities in all the projects in that group, and a list of
actionable entries that can be used to start a remediation process. For example, you can open an issue
with a suggested solution, or simply dismiss the entry if you classify it as a false positive.
Support for other tests (Dependency Scanning, Container Scanning, DAST) will be added in the future.
Note: The Group Security Dashboard requires the new reports
syntax and GitLab Runner 11.5 or higher in order to display results.
Auto DevOps will be supported in a future release.
For organizations who have embraced DevOps, and for teams with more operations-leaning members, it is important to be able to quickly
ascertain the health of the projects in your organization.
GitLab 11.5 introduces a new, operations-focused dashboard, providing a summary of the key operational metrics of each project
a user is interested in. This includes the time since the last deployment, most recent commit, as well as whether there are any active alerts.
The dashboard can be set as a user’s preferred homepage, or accessed via clicking on the new dashboard icon in the top bar.
The 11.5 release introduces a fantastic new community-contributed feature which enables
access control for Pages. Now, instead of only supporting use cases where the content
associated with the product is public, you can use Pages to build and publish protected
content that should only be accessible by project members. Operational documentation, internal
secrets, or even just private planning or other information can now be confidently published
automatically in an easy-to-access way, while ensuring only the right people are able to see
it.
This is currently not enabled on GitLab.com, you can follow
issue 5576
for more information.
Building serverless applications enables teams to focus their time on making a great product
and eliminates the need of provisioning, managing, and operating servers.
Starting in GitLab 11.5, you can now deploy Knative to your
existing Kubernetes cluster with a single click using the GitLab Kubernetes integration. Knative
is a Kubernetes-based platform to build, deploy, and manage modern serverless workloads. Tasks that
were once difficult, such as source-to-container builds, routing and managing traffic,
and scaling-to-zero, now work effortlessly out of the box.
Knowing who to ask to review your merge request isn’t always obvious.
Code Owners, which allow files to be assigned to the responsible team
members, are now automatically assigned as merge request approvers.
Assigning approvers automatically based on Code Owners will notify the
relevant Code Owners of impending changes so that they are able to
review and approve the changes.
Support for defining Code Owners was introduced in
GitLab 11.3. In
upcoming releases, Code Owners will be further integrated into the
merge request workflow with
required approvals.
The speed of pipelines is an important factor for any team, and running tests or other parallelizable tasks
tends to take a big chunk of the time for any build. Adding this new keyword gives teams the ability to
simply parallelize tests, allowing everyone to accelerate their software delivery process. To use this
feature, simply set the parallel attribute to how many copies of the task you’d like to split it into,
and GitLab will handle the work of automatically creating the appropriate number of jobs running your task.
An important purpose of code review is to draw attention to aspects of
the proposed change that may not have been considered. Often this means
pointing out unforseen consequences in areas of the code base that are
unchanged.
GitLab now supports commenting on both changed and unchanged lines in
merge request diffs, so that you can directly draw the attention of the
author to changes that are required that have not yet been made. When
reviewing a merge request diff you can expand collapsed, unchanged lines
using the ellipsis (…) button.
In upcoming releases, support for commenting on unchanged lines will be
expanded from changed files to
unchanged files.
When you’re working on a branch and have only changed a few files, it’s not very helpful for the
Review App link to take you to the root of the website. To make this more useful, we’ve added a
dropdown selector to the Review App link which can now take you directly to the page(s) that you’ve
changed.
Code review is an essential practice of successful projects, but
providing clear and actionable feedback can be difficult. A particular
challenge is avoiding leaving comments that become irrelevant or
incomplete as one’s understanding of the changes improves as one reads
more of the diff.
With this release you are now able to preview your merge request review
before submitting. Merge request reviews, introduced in GitLab 11.4,
allow reviewers to draft many items of feedback and submit them all as
a single action.
In future iterations, we will improve the feature to send
one email notification
per merge request review.
Before GitLab 11.5, reports like SAST or DAST relied on a combination
of job and artifacts names to be recognized as such by the system. This
was not optimal to scale and to support more advanced features
like the Group Security Dashboard, because of the performance implications to access artifacts. With the previous syntax you needed to use specific job names (like sast) but now you can specify custom job names.
In GitLab 11.5 a new implementation has been introduced to leverage the new reports syntax. New job
definitions are now available for
SAST,
DAST,
Dependency Scanning,
Container Scanning,
License Management,
Code Quality, and
Browser Performance Testing.
The old syntax has been deprecated and could be removed in a future release.
You are encouraged to upgrade your definitions in order to benefit from improved
performances and the Group Security Dashboard, even if the old syntax is still working.
The new syntax requires GitLab Runner 11.5 or above.
We’ve improved the experience for Wiki-only projects without a default
project overview page.
The empty state for this project setup now better encourages users to add
a page to the relevant Wiki and get these projects off to a great start.
It is now possible to configure status checks on the GitHub side that can be marked as “required”
without having to configure this one by one, based on their name. Previously, the check
names included the branch name, so it was not possible to do this easily. This feature is
enabled via the GitHub integration configuration section.
We recently released the ability to close epics, namely having different
open and closed states for epics. In this release, we are adding notifications
for closing and reopening epics, to help users follow more closely on work
they are interested in.
You can now more easily search and refer to epics while working in an issue
or merge request. Just type & and enter a few numbers or characters in
the issue or merge request’s description or a comment. GitLab’s autocomplete
will search for epics in the immediate parent group, allowing you to select
one easily all without leaving the current page.
Currently, environment information is hidden when a newer pipeline is running. With this change
we are adding information on in-progress deployments to the widget, so you know that an update
is on its way.
One of the most exciting results of this functionality in this release is that the link to the
current deployment will remain available in cases where a new deployment is running, allowing
you to still find the link to the Review App. In cases where lots of deployments were constantly
running, this previously made it quite difficult to get the timing right in some cases.
As teams use more and more issue boards, it can become cumbersome to navigate
among many of them in the dropdown navigation. With this release, GitLab
will automatically send you to the last visited board, whenever you access
the boards navigation from the sidebar menu of a given project or a group.
This is saved to the system, so even if you use GitLab between different
browsers and devices, the last visited board will be saved.
Note that you can still directly link to a specific board by saving the
URL of the board when you are viewing it.
GitLab milestones are useful for teams to plan and track work to be done
in a time-boxed period or to associate with a code release. These dates
are important for teams to communicate timelines with each other and
stakeholders in general. So when milestones change, it is critical that
people are updated.
With this release, we’ve added email notifications for changing milestones
in issues and merge requests, so that people can stay updated if a piece
of work has been delayed, moved earlier, or just de-scoped.
A central place of collaboration in GitLab is Issue Boards, where teams
can organize and view planned and ongoing work in one location. With this
release, we’ve improved the design of issue cards, showing relevant information
in a simple and organized manner. We are showing the issue title, time-tracking
information, confidentiality, labels, due date, weight, and assignee, all
in the card.
Securing Kubernetes instances is paramount for running production-ready, mission-critical apps. RBAC
provides great power and flexibility in securing your cluster.
Starting in GitLab 11.5, our Kubernetes integration will create a dedicated service account and role
binding for each project’s namespace which will be used in GitLab CI jobs. This eliminates the need to
use the cluster-admin token when interacting with GitLab CI runners.
Git submodules allow you to include a Git repository within another Git
repository. GitLab now supports updating the submodule reference via
the API. This is particularly useful for automation, allowing you to
keep your project up to date with the latest dependencies using the
API.
In this release, we’ve improved the design of discussion activity in issues,
merge requests, and epics. We’ve made it easier to read comments and parse
system note activity, so you can focus on the information that’s relevant to
you at the given moment.
With this release, we are aligning the ‘New group’ page with the ‘New
project’ page, consolidating and repositioning relevant fields for clarity
and consistency.
Dependency Scanning
relies on the Gemnasium service for the
majority of supported languages. This allows GitLab to report known vulnerabilities in packages, but
this information was missing a remediation that helps developers to easily fix the problem.
With GitLab 11.5, Gemnasium service provides remediations every time the information is available.
This is then reported in the vulnerability details window, and in the related issue. For example, the
remediation could report the minimum version a library should be updated to in order to fix the security
problem.
LDAP and OmniAuth settings have been unified in the global settings, making it easier to configure. Users currently configuring it individually for each subchart will need to update their settings to upgrade to 11.5.
We’re also releasing GitLab Runner 11.5 today! GitLab Runner is the open source project
that is used to run your CI/CD jobs and send the results back to GitLab.
File templates for LICENSE, .gitignore, Dockerfile, and
.gitlab-ci.yml files make it easy to add these common files to
projects. Custom file templates can now be shared with all the projects
in a group and sub-groups, by configuring a template repository for the
group.
Custom templates are useful when the templates provided by GitLab are
too generic, for example a custom license that should be used for every
project in the company, or a complex Dockerfile that should be used for
every microservice.
In this release, we have provided a dynamic chart showing the number of
issues created in your group, per month, for the past year. There is even
a filter that allows you to filter down to a particular scope of issues.
This will help teams dig more deeply into their issue analytics. For example,
you can quickly see how many bug issues have been created, if you use a
bug label.
It’s important to know who is contributing code to your project and be
able to look up a commit author in the GitLab interface, using Git locally,
or on a fork hosted elsewhere, but this exposes your email publicly.
GitLab now provides a noreply email address that can be used locally
and for web commits to help make it easier to keep your email address
private.
GitLab has supported opening a merge request via email for a long time,
but before sending the email the branch must already exist on the
server. Now you can open a merge request with only an email by
attaching one or more patch files (.patch).
Patch files are the standard for sharing and transmitting changes
between systems. In future releases of GitLab we will build on this
foundation for
distributed merge requests,
which will allow merge requests between GitLab instances, and other
Git hosting tools too.
Tracing provides deep introspection into the performance and health of a deployed application, tracking each function or microservice
which handles a given request. This makes it easy to understand the end-to-end flow of a request, regardless of whether you are using
a monolithic or distributed system.
GitLab 11.5 includes an initial integration with Jaeger, the CNCF-hosted tracing project,
allowing users to easily open the Jaeger UI from GitLab.
GitLab includes a number of Go-based applications. Prior to 11.5, these applications utilized the standard OS
system location for trusted certificates, instead of the Omnibus GitLab directory.
With this release, Go applications now use the same directory for trusted certificates as the rest of GitLab,
by default /opt/gitlab/embedded/ssl/certs/, making certificate management easier and more straightforward.
GitLab installations which depended upon the Go applications using the system directory should move those certificates
to the standard Omnibus GitLab location.
In order to make audit events easier to analyze and ingest outside of GitLab, we’ve added audit_json.log to
capture audit events in a structured log file. With this change, shipping and parsing logs becomes much easier –
especially for visualization and analysis in other tools.
Moving backwards and forwards between files in the merge request diff
is necessary in all but the smallest of changes. In addition to the
file tree added in
GitLab 11.4,
GitLab now includes a searchable file list of changes to
make it easy to see which files have changed and jump between them,
whether you prefer a tree or a list.
Jira Cloud is removing usernames for authentication.
So to support this change, we now allow you to use an email address and
API token to authenticate with Jira Cloud instead.
We recently released the ability to close epics, namely having different
open and closed states for epics. In this release, we are exposing that
state in the API itself, so that you can filter on open or closed epics
when retrieving a list of them, as well as see the state in a single epic
retrieved itself.
Similar to issues and merge requests, you can perform basic operations in
an epic page with keyboard shortcuts, helping those users who want to get
more done, more quickly, without leaving the keyboard.
Use r to start a new comment. (It will even quote selected text.)
Use e to edit the description. And use l to change
labels.
When a README.* file is present in a directory of a repository, it’s
rendered automatically by GitLab without the need to explicitly
open it. With GitLab 11.5, it’s now possible to do the same thing with
an index.* file.
This is particularly useful when you also deploy your content online
using a static site generator. Previously, if you used README.md it
would render to README.html, whereas with index.html you can now
have clean URLs since most web servers treat
http://example.com/page/index.html and http://example.com/page/ the
same.
This is not limited to Markdown files as GitLab supports a number of
markup languages.
We are glad to see teams collaborating actively in issue and merge request
comments. For more involved discussions and longer-lived issues and merge
requests, the discussion activity can become very long, with a lot of generated
system notes.
With this release, we’ve implemented a filter to allow you to focus on just
comments or system activity in the discussion area of an issue or merge request.
Your selection is saved for all issues or all merge requests in GitLab.
So if you prefer one mode, you can just make the selection once, and it
will persist forever.
Every time you push changes to a Git repository on GitLab, GitLab
performs checks on each commit to enforce permissions, repository size
restrictions and validates the presence of LFS objects. In some cases
large pushes can fail without feedback when validation takes too long.
GitLab now provides feedback when Git push operations time out because
validation is taking too long. This will help debug the source of the
problem by providing better feedback to the user.
With GitLab 11.5, we are iterating on the settings page of Groups to
prioritize the most sought-after configuration options. The top-most
section is expanded by default, and we’ve clarified labels and links to
provide clear direction on where to find settings and what they do.
We’re continuously working on this – Project and Admin settings improvements
are coming soon!
With this release, we are updating the top navigation bar by moving two
items into a new, dedicated Help menu section.
We’ll continue to add additional items there related to instance-level
support and feedback in future iterations coming soon!
With this release, we are updating the activity dashboard design to give a better view into who is
doing what in your GitLab instance. The new activity feed gives a reader more context on what
actions have taken place to keep you always up to date.
sast_container value in GITLAB_FEATURES environment variable
The GITLAB_FEATURESenvironment variable,
available to CI/CD jobs, lists all the available features based on the current license/tier.
The sast_container value for Container Scanning
is now deprecated, and replaced with container_scanning. The old value could be removed in GitLab 12.0.
Old CI/CD syntax for security, quality, and performance report types
Before GitLab 11.5, jobs and artifacts had to be named specifically to automatically extract report data and show it in the merge request widget.
While these old job definitions are still working, they have been deprecated and may be removed in the next major release, GitLab 12.0.
Pipelines older than three months are no longer re-runnable
As of this release, older jobs (>3 months) will no longer be allowed to be “played” or “retried,” and rollback
will no longer be available. As of now we are not actually deleting this data so we can receive feedback on
potential problems with this change. Please join the discussion in #50939 if
you have concerns.
Elasticsearch 5.5 and earlier not supported in GitLab 11.5
GitLab 11.5 will no longer support Elasticsearch 5.5 and below. It will only
support Elasticsearch 5.6 and 6.x. See the blog post
for additional details.
With GitLab 11.4 (Oct. 22, 2018) the bundled Prometheus 1.0 version is deprecated in Omnibus GitLab. Prometheus 2.0 is now included,
however the metrics format is incompatible with 1.0. Existing installations can upgrade to 2.0 and optionally migrate their data using an included tool.
With GitLab 12.0 any installation not yet running Prometheus 2.0 will be automatically upgraded. Metric data from Prometheus 1.0 will not be migrated, and will be lost.
To upgrade to GitLab 11.5 from the latest 11.4 version, no downtime is required. To upgrade without downtime, please consult the documentation on downtimeless upgrades.
For this release we have migrations, post-deploy migrations, and to help with the larger migrations we have introduced background migrations.
GitLab.com migrations took approximately 9 minutes and post-deploy migrations amounted for a total of around 32 minutes. Background migrations on the other hand are sidekiq jobs that will run synchronously, for this release these migrations took around 2 days to complete, no side effects were expected nor present, these target older kubernetes cluster integrations so newer kubernets cluster integrations are not affected.
GitLab Geo users, please consult the documentation on upgrading Geo.
Go apps in Omnibus now use the standard GitLab certificate directory. Installations which depended upon the Go applications using the system directory, should move those certificates to the standard Omnibus GitLab location.
We want to hear from you
Enjoyed reading this blog post or have questions or feedback? Share your thoughts by creating a new topic in the GitLab community forum.
Share your feedback