mnonnenmacher
commented
1 month ago The generic concept for credentials in the server are InfrastructureServices. 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:
- Add an implementation of EnvironmentConfigGenerator which can create the private key file.
- Add API endpoints to configure environment services.
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.
sschuberth
Etsija
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.