Add SSH key security disclaimers and 1Password recommendations

Why is this change being made?

Some of our SSH key generation instructions lack security guidance. Currently, the labs guide users to generate and store SSH keys directly on disk without highlighting the security risks or recommending best practices.

This creates a potential security concern because:

  • Users following these labs may adopt insecure practices of storing private keys on disk
  • There's no mention of more secure alternatives like 1Password for key management
  • The labs don't emphasize that private keys should be protected and never shared

By adding security disclaimers and recommending 1Password for SSH key generation and storage, we:

  • Educate users on secure key management practices from the start
  • Align with GitLab's security standards and best practices
  • Provide clear guidance on using 1Password, which offers better protection for private keys and aligns with our Password guidelines
  • Help prevent security incidents caused by improperly stored SSH keys

This change makes the handbook more helpful by not just teaching the "what" (how to generate SSH keys) but also the "why" and "how to do it securely" - supporting our value of transparency and helping users make informed security decisions.

Author and Reviewer Checklist

Please verify the check list and ensure to tick them off before the MR is merged.

  • Provided a concise title for this Merge Request (MR)
  • Added a description to this MR explaining the reasons for the proposed change, per say why, not just what
    • Copy/paste the Slack conversation to document it for later, or upload screenshots. Verify that no confidential data is added, and the content is SAFE
  • Assign reviewers for this MR to the correct
    • The when to get approval handbook section explains when DRI approval is required
    • The who can approve handbook section explains how to identify the DRI
    • If the MR does not require DRI approval, consider asking someone on your team, such as your manager.
    • The approver may merge the MR. If they approve but don't merge, you can merge.
  • For transparency, share this MR with the audience that will be impacted.
    • Team: For changes that affect your direct team, share in your group Slack channel
    • Department: If the update affects your department, share the MR in your department Slack channel
    • Division: If the update affects your division, share the MR in your division Slack channel
    • Company: If the update affects all (or the majority of) GitLab team members, post an update in #whats-happening-at-gitlab linking to this MR

Edited by Peter Arts

Merge request reports

Loading