Introduction
Suppose you have 250 servers in your organization and 10% of them are not used in production; you also have 15 people on your engineering team, with 5 of them being contractors. How do you manage who gets SSH access to what…and how do you deal with people joining and leaving the team or changing roles? And how do you make sure a lost laptop doesn’t lead to a larger compromise?
With the increasing frequency and severity of data breaches at companies like Equifax, Yahoo, Target, and Uber, and larger amounts of data being dispersed across cloud services, information security is top of mind for both large enterprises and startups. Large companies like Facebook, Lyft and Netflix often have the security teams and resources to architect DIY solutions or purchase custom solutions to address their concerns.
This blog post describes how to simply and effectively manage SSH credentials for smaller teams through their Github team membership using open source tools.
The management of SSH keys at a startup is often left up to the collective responsibility of the engineering team. When that team is small and capable, it may not a be an immediate problem. Yet, we are surprised how often we meet teams who have a shared public key called something like ops.pem which gets replaced and re-distributed every time the team changes…and usually someone forgets to replace it at some point.
SSH Certificates
This blog post offers a better way, based on two simple principles:
- Your SSH infrastructure, instead of relying on forgotten artifacts on servers (public keys), should rely on an external identity system common for everyone in your organization.
- Instead of SSH keys, use automatically expiring SSH certificates to grant someone access to a subset of infrastructure for a limited amount of time.
#github
