Improve auditability and manageability of deploy keys
We had a customer call today about finding ways to make GitLab be able to manage service account credentials effectively. Right now the customer has thousands of users broken down into two categories:
- Users managed by Active Directory
- Service accounts
Right now access to the GitLab server is restricted via a VPN that requires Active Directory access. That makes it possible to restrict GitLab easily: when a user leaves the organization, he/she loses network access via a change in the LDAP server. However, the customer wants to be able to expose their GitLab instance in the cloud to people outside the VPN, and that's where things become tricky with service accounts.
For example, any user can add SSH deploy keys to a project. What happens if users leave the company? It's possible that even though their GitLab accounts are deactivated that they still retain access to Git repositories via a key added quietly on the side. The customer doesn't want to blindly remove keys when users leave or put in blanket expiration dates because a lot of their tools (e.g. Jenkins) rely on those credentials to be working.
Some ideas of how GitLab could help:
- Auditability: Better visibility of which deploy keys created by which user
- Automatic expiration: Automatic disabling of deploy keys that have not been used in X days. Make it possible for service accounts to regenerate these automatically.
- Tooling: Customer has thousands of deploy keys at the moment. Any tool that allows them to automate whether keys are in use would help.
Customer is looking at other ideas:
- Adding multi-factor authentication with something like Symantec VIP
- Using CyberArk to grant temporary passwords
@briann I would like to get your ideas on this topic. It's not a simple topic, but something we need to design for as I imagine many companies will have similar concerns.
/cc: @MikeWalsh, @mydigitalself, @victorwu, @Haydn