User impersonation audit events for groups
GitLab now provides audit events on the group audit events page for user impersonation starting and stopping. This was previously only available on a page unavailable to GitLab SaaS customers. We are excited to bring it to the group page which allows both self-managed and SaaS users to view these events!
These events are helpful to understand if an administrator impersonated a user in your group and any actions that the administrator took as the impersonated user. You can correlate:
- Any actions a user took.
- When impersonation was happening.
This can help you understand if it was actually the user performing certain actions or an administrator impersonating them. The absence of impersonation events in the audit log is also a way to be confident that a given user actually performed given actions, rather than someone impersonating them.
Additional display options for roadmaps
In this release, we have introduced additional progress tracking capabilities to roadmaps. You can now view the percentage of completed epics based on issue count instead of issue weight. This functionality is useful for organizations that are using Kanban or other methodologies that don’t require their teams to set a weight on issues.
You can now also customize the level of milestones to include in your roadmap, allowing you to tailor your view to meet the needs of your audience.
Security approval policies
GitLab now supports flexible security approvals as the replacement for the deprecated Vulnerability-Check feature. Security approvals are similar to Vulnerability-Check in that both can require approvals for MRs that contain security vulnerabilities. However, security approvals improve the previous experience in several ways:
- Users can choose who is allowed to edit security approval rules. An independent security or compliance team can therefore manage rules in a way that prevents development project maintainers from modifying the rules.
- Multiple rules can be created and chained together to allow for filtering on different severity thresholds for each scanner type.
- A two-step approval process can be enforced for any desired changes to security approval rules.
- A single set of security policies can be applied to multiple development projects to allow for ease in maintaining a single, centralized ruleset.
Security approval policies can be used alongside the existing Vulnerability-Check feature, as the two policies are additive and don’t conflict. However, we encourage users to migrate their Vulnerability-Check rules over to security approval policies. Vulnerability-Check rules are now deprecated, and are scheduled for removal in GitLab 15.0. Self managed users will need to enable the
scan_result_policy feature flag prior to using this feature. To get started, navigate to Security & Compliance > Policies and create a new Scan Result type policy.
Auto-completion of keywords in the Pipeline Editor
Writing a valid GitLab CI/CD pipeline can be difficult regardless of whether you’re a novice or more advanced user. Syntax structure should be accurate and even a small typo or misconfiguration could cause your pipeline to be invalid, introducing more work to find the source of the problem. In this release, we’ve added auto-completion of CI/CD keywords to the pipeline editor, which will greatly increase your efficiency when writing and debugging pipelines. You’ll be more confident that your pipeline will run the way you want it the very first time it runs.