Open sschuberth opened 2 months ago
The generic concept for credentials in the server are InfrastructureService
s. They associate a URL with a pair of username and password credentials. The actual secrets must be stored in a secret storage.
Infrastructure services can either be defined in the database via the API or in an .ort.env.yml
file (for example see: https://github.com/eclipse-apoapsis/ort-server/tree/main/workers/common/src/test/resources). For checkout credentials only the database approach works, because the .ort.env.yml
is only available after the checkout.
Currently, the API only provides endpoints to configure infrastructure services for an organization. The data model would also to associate them with products but no API endpoints for that have been implemented. In the future it might also make sense to define infrastructure services for repositories.
The infrastructure service definition for Git checkout credentials could look like this:
{
"name": "GitLab",
"url": "https://gitlab.com/",
"description": "GitLab credentials",
"usernameSecretRef": "gitLabUsername",
"passwordSecretRef": "gitLabPassword",
"credentialsTypes": [
"NETRC_FILE", "GIT_CREDENTIALS_FILE"
]
}
If this infrastructure service is defined for an organization, a .netrc
and a .git-credentials
file would be generated for all repositories where the URL starts with "https://gitlab.com/". If different credentials are required for different repositories from the same host, the longest match is used. For example, if an additional infrastructure service with the URL "https://gitlab.com/sub/" is defined, this would be preferred for all repositories that start with that string.
The credentialsType
property is optional and defaults to only NETRC_FILE
which is sufficient in most cases. However, for Git repositories hosted on Azure this did not work and support for GIT_CREDENTIALS_FILE
was added.
Cloning with SSH is currently not supported. To make it possible, two things would have to be done:
To make this configurable via the UI, we would need screens to configure secrets and infrastructure services for organizations, and later also for products and repositories.
The current approach might not be the most convenient way to configure repository credentials and could surely be improved later on. However, as it works and we have many more urgent tasks on our list, this would not be high priority for us.
To make this configurable via the UI, we would need screens to configure secrets and infrastructure services for organizations
Actually, I would not expose the user to the low-level concepts of secrets and infrastructure services, but just call the concept "credentials" with an "unusual" additional property that names the host prefix.
Actually, I would not expose the user to the low-level concepts of secrets
Turn out we need to manage secrets directly also for other uses than credentials, see https://github.com/eclipse-apoapsis/ort-server/issues/659.
Basic implementation is done with #761 but one workaround was needed due to #758 which needs to be removed once that issue is solved.
In order to access private repositories, we need a way for users to add credentials to access these. Credentials usually are a pair of secrets, like username and password (e.g. for cloning Git over HTTPS) or a "generic" username and a private key / token (e.g. for cloning Git over SSH).
User should be able to CRUD such credentials on a repository level. But also, multiple credentials should be configurable on the product and organization levels, which are "inherited" by deeper hierarchies and can be references from there. For example, it should be possible to create credentials on the product level, have no credentials on the repository level, but still refer to product-level credentials in order to clone the repository.
As IIUC ORT server only knows about the lower-level concept of secrets, not credentials, we probably also need to come up with some sort of naming convention for secrets in order to determine which pairs of secrets belong together in order to form credentials.