nsheridan
Adding Gitlab groups as principals / Dockerfile improvements
When setting cashier up, I thought back to this post and about using Gitlab group membership as principals to map to usernames.
Sadly, this isn't supported but I'm guessing more people might want this. I've included and tested the implementation for gitlab, and added noop methods for the other providers.
Furthermore, I adjusted the Dockerfile to save a little space:
- Command go to create smaller binaries . I've tried using UPX too, but it's too much of a hassle as it isn't in Alpine stable yet.
- Merge several commands into a single RUN line creating fewer layers
- Purge build dependencies after build
- Remove sources
I think the approach of passing group membership information in certificates as a static list of principals might not be the best approach as it means that group memberships are now tied to certificate lifetime instead of source lifetime in Gitlab i.e. you can be removed from a group and still have certificates that permit you to access resources relying on that group membership.
I think a better approach would be instead to use the AuthorizedPrincipalsCommand in OpenSSH itself to check these permissions dynamically at access time.
@patrickod point taken. To put this into perspective:
Same principle does apply to the user account's validity though. Deactivate it in Gitlab, and the certificate is still valid until the expiration date.
When using LDAP in the auth source system in a regular sync job manner, account locks/group removal may take up to the configured synchronisation interval.
Rigging OpenSSH to query Gitlab et al. does introduce a potentially unwanted direct dependcy on the auth system.
Without setting up OpenSSH, the introduction of the groups as principals has no effect.
So I'd recommend adding a paragraph to the docs detailing this problem and informing about the risks and leaving it to the admin setting this up to make the decision.
Do ya'll know if there is any upstream work in OpenSSH or within a standards body to codify how extended attributes to SSH certificates should be handled by SSH implementations? Gravitational's Teleport system can be used with OpenSSHD's CA + Github Groups via oauth, basically encodes group membership in the issued certs. But older openssh versions would fail on unrecognized extensions to certs. It would be nice if there were a standard around encoding metadata in SSH certificates.
