SPIFFE Authentication Support
Everyone can contribute. Help move this issue forward while earning points, leveling up and collecting rewards.
Background
Very briefly: SPIFFE is an open standard that helps create a foundation for zero-trust based systems based on cryptographic identity. SPIRE (mentioned in a related linked item) is an open source implementation of that standard. More can be found on spiffe at https://spiffe.io
SPIFFE essentially provides a framework for workloads to get their own cryptographic identity. A "workload" might be
- actual engineering flows, e.g. a gitlab pipeline or Jenkins pipeline or just some script started by cron on a bare metal host OR
- services in their own rights, e.g. a GitLab server, a Jenkins server, an Artifactory server or any other service
This identity is implemented either by a JWT or a x509 cert (and private key). From a security standpoint, we are preferring the x509 cert at the moment, as it can be used via standard mTLS; and also prevents masquerading threats as unlike with a JWT, you are not trusting the remote service you gave it to (so as to auth at all) not to do anything nefarious with the token.
The identity is essentially a URI: spife://(some.domain)/(some/hierachical/path)
so that might be e.g. spife://eu.arm/line-of-business/project/flow-name
As a multi-cloud provider consumer and many different (engineering) service consumer, we're looking to try and use SPIFFE essentially as a single sign on for non-interactive engineering flows as well as service firewalling at L7 (essentially service-mesh).
So an engineering workflow can contact a service (such as gitlab, a different git service, another data service such as Artifactory, or "Big Data" ML service, or even cloud services such as an AWS-S3 bucket) and just give its certificate to access. e.g. We can bridge in all AWS services this way using AWS's roles via mTLS anywhere
Feature Request
- We'd like to be able to use spiffe through mTLS for API auth to GitLab as a server
A first hack integration could be simply having a "user" corresponding to the spiffe-id and having that have associated permissions within GitLab.
We can also do this bit ourselves to some extent by just using a reverse proxy in front of gitlab to handle the mTLS and then forward on to GitLab and use some internal translation as a given user; depending on what (if any) options GitLab has for this.
- We'd like for GitLab as a service to be able to act as a SPIFFE attestor for flows it starts. Similar to what is currently happening with JWTs that flows get access to at the moment where essentially GitLab is attesting back to a spiffe server (e.g. spire) that flow running under it is just that.
A first hack here might be for the runner itself that starts the job on the remote end to be able to use its existing GitLab JWT to use that to obtain a requisite SPIFFE cred. So for example if a GitLab service itself had a spiffe id of (say) spiffe://somewhere.arm/eit/iac-gitlab, then for a pipeline it might attest that this for an identity spiffe://somewhere.arm/eit/iac-gitlab/ID - where ID is the pipeline's id or nicer would be a more human readable project and branch.
The above is really just a first thoughts high level view just to give an idea and there are many other possible implementation routes.