Skip to content

Pre-defined SSH key expiration period ("lifetime")

Problem to solve

Many companies have policies requiring password changes every few months. As a user credential, GitLab SSH keys usually fall under these policies. Compliance-minded organizations do not have a way to set a namespace-wide expiration policy for SSH keys, which can create a gap in their audit posture around security controls for user credentials.

Proposal

  • Add an Maximum allowable lifetime for SSH keys (days) field to Admin > Settings > General > Account and limit. (Very similar to the feature for Personal Access Tokens.)
  • If set, use this value to pre-populate a value for the "Expires at" field that appears when a user is adding an SSH key. If the Enforce SSH key expiration option is enabled, then that value should not be modifiable by the user.

Implementation plan (backend)

  • Add an instance-level option "SSH expiry can be up to X days from creation".
    • Overridden with null (no restriction on expiration date) if:
      • Licence is not Ultimate
      • SSH key expiration is not enforced.
  • When a user adds a new SSH key, they must set an expiry that is no further than X days in the future otherwise validation fails.

Further details

Previously, we implemented #36243 (closed) which adds a user-facing, optional SSH key expiration field to Avatar > Settings > SSH Keys > Expires at. This was optional for users and admins and group owners could not set or enforce this expiration.

We will also be implementing #250480 (closed), which will make the programmatic, backend enforcement job optional. This will help avoid disruptive default behaviors in GitLab to preserve the developer experience as a default experience. This issue adds a toggle to make automatic enforcement of an SSH key expiring optional or not.

This issue - #1007 (closed) - adds an admin area policy enforcement capability to GitLab. Once all three of these issues exist, the experience will be:

  1. An admin defines an instance-wide SSH key expiration policy (#1007 (closed); this issue)
  2. An admin sets enforcement of SSH keys (when they reach the expiration date) optional. This means an SSH key can expire but alternative alerts will be used to notify stakeholders without automatically deleting the key. This is minimally disruptive to developers and is an optional setting.
  3. A user can optionally set their own expiration date on an SSH key, but it will be subject to any defined instance-level policy. e.g. A user can set an SSH key to expire after 45 days, but an instance policy of 30 days will take priority and the user's SSH key will expire after 30 days.

Future iterations

  1. New issue: Generate an email to the user 7 days before their SSH key expires
  2. New issue: Generate a batch email to admins with X number of expired credentials for the week that require attention (if enforcement is optional)
  3. New issue: Create a CLI error message to inform users their key is going to expire (7 days prior to expiration)
  4. New issue: Create a CLI error message to inform users their key has expired (where enforcement is optional)

Product tier level

GitLab Ultimate

Links / references

This customer has written a custom script to do this and asked if we would support it natively: https://gitlab.my.salesforce.com/0016100000UKiJi

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.

Edited by 🤖 GitLab Bot 🤖