<!-- This issue template can be used as a great starting point for feature requests. The section "Release notes" can be used as a summary of the feature and is also required if you want to have your release post blog MR auto generated using the release post item generator: https://about.gitlab.com/handbook/marketing/blog/release-posts/#release-post-item-generator. The remaining sections are the backbone for every feature in GitLab. The goal of this template is brevity for quick/smaller iterations. For a more thorough list of considerations for larger features or feature sets, you can leverage the detailed [feature proposal](https://gitlab.com/gitlab-org/gitlab/-/blob/master/.gitlab/issue_templates/Feature%20proposal%20-%20detailed.md). --> ### Release notes TBD ### Problem to solve On GitLab.com customers obtain their own top-level group (later organization). In comparison to self-managed, they have to manage organization-wide settings at this level. Currently, the provided git access control options on SaaS (SSH, HTTPS) rely on credentials (access tokens, SSH keys) setup in the user profile. As the user profile is out of control of the organization, there is no way for a customer to assess that the key is kept confidential nor whether the expiry date is meeting policies. Also, there's very little that can be done for damage control in case the keys are leaked as well as a customer cannot enforce MFA on Git access flows. Customers may have processes in place, where developers on a daily basis can, via MFA, request a temporary SSH certificate which gives them access to internal systems. To enable the same way of working on SaaS, we would need a way to share public CA certificates with Gitlab.com SaaS for the purpose of Git access control. This feature would require: 1. [Add support for authentication via SSH certificates in gitlab-sshd](https://gitlab.com/gitlab-org/gitlab-shell/-/merge_requests/660) 1. Enable configuration of (multiple) SSH certificates to be trusted for Git access control 1. Add the ability to enforce the use of these certificates for Git access. We do not want people to bypass this with personal access tokens or SSH keys Optional, maybe for later iterations: It would be awesome if the above would integrate with the recently added option to add SSH certificates to sign git commits. Although a separate feature, it would make sense to keep this in mind as it would touch upon the same code: 1. Allow setting usage type for configured SSH certificates (Authentication, Signing, both), similar to how this is implemented in the SSH key section in ones GitLab profile 1. Add ability to enforce the use of these certificates for Git signing. We do not want people to bypass this with personal SSH keys ## Motivation - Enable users to share public Certificate Authority (CA) files with GitLab.com SaaS for the purpose of Git access control. - Fill the product gap between GitLab and competitive products that already support authentication via SSH certificates. ## Architecture It's a joint effort of ~"group::source code" and ~"group::authentication and authorization" because ~"group::source code" is responsible for [Gitlab Shell](https://gitlab.com/gitlab-org/gitlab-shell) project and ~"group::authentication and authorization" owns Authentication topic Blueprint: https://docs.gitlab.com/ee/architecture/blueprints/ssh_certificates/ ```mermaid sequenceDiagram User->>+GitLab Shell: Auth using SSH Certificate GitLab Shell->>+GitLab Rails: /authorized_certs?key=fingerprint-of-signing-key&user_identity=username-or-primary-email GitLab Rails-->>-GitLab Shell: responds with the namespace that configures the CA and the username of the user GitLab Shell-->>User: Authenticated successfully User->>+GitLab Shell: Git command to a specific project GitLab Shell->>+GitLab Rails: /allowed [namespace=namespace] GitLab Rails-->>-GitLab Shell: responds that the user is allowed to access a project in this namespace GitLab Shell-->>User: success ``` ### Intended users Personas are described at https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/ * [Cameron (Compliance Manager)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#cameron-compliance-manager) * [Sasha (Software Developer)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#sasha-software-developer) * [Priyanka (Platform Engineer)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#priyanka-platform-engineer) * [Sidney (Systems Administrator)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#sidney-systems-administrator) ### Feature Usage Metrics <!-- How are you going to track usage of this feature? Think about user behavior and their interaction with the product. What indicates someone is getting value from it? Create tracking issue using the Snowplow event tracking template. See https://gitlab.com/gitlab-org/gitlab/-/blob/master/.gitlab/issue_templates/Snowplow%20event%20tracking.md --> <!-- Label reminders Use the following resources to find the appropriate labels: - Use only one tier label choosing the lowest tier this is intended for - https://gitlab.com/gitlab-org/gitlab/-/labels - https://about.gitlab.com/handbook/product/categories/features/ --> <!-- triage-serverless v3 PLEASE DO NOT REMOVE THIS SECTION --> *This page may contain information related to upcoming products, features and functionality. It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes. Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab Inc.* <!-- triage-serverless v3 PLEASE DO NOT REMOVE THIS SECTION -->