We've recently adopted the GitLab dependency proxy for our project on a self-hosted GitLab instance.
This works fine for normal users, but fails for pipelines created via the API using a project or group access token, regardless of access level.
We've tried with a project token that has API permission and a developer role as well as a group account with that permission and developer role.
We also tried to grant the tokens permission for read_registry, write_registry to no avail.
The outcome is always the same: Any pipeline triggered by a Token/Bot user runs into a wall where it says you're not authenticated to access the dependency proxy because no credentials were specified. If I restart the very same job as a human user from the UI everything works just fine.
How do I need to configure my access tokens so that their corresponding bot users can access the dependency proxy?
The issue is most likely about using wrong credentials.
According to the documentation, it won't work with project access token, or group access token – only personal access token & group deploy token besides username & password are supported.
Now let's say we want to use group deploy token. The docker-machine executor usually uses $CI_DEPENDENCY_PROXY_USER & $CI_DEPENDENCY_PROXY_PASSWORD (source) to authenticate to $CI_DEPENDENCY_PROXY_SERVER, as those variables are set up automatically.
Those credentials are the same as $CI_REGISTRY_USER & $CI_REGISTRY_PASSWORD (source) – the password in both cases is the job token. The job token has the same permissions as the user, and as mentioned above, group access token and project access token do not have access to the dependency proxy.
According to the deploy token documentation, you should authenticate to dependency proxy using the username (of the group deploy token) & token instead. To achieve that, I think the only option would be to embed deploy user & token inside $DOCKER_AUTH_CONFIG CI/CD variable.
I have not tried such scenario but I think it should work.
For docker-in-docker, you should be able to set DEPLOY_TOKEN_USERNAME & DEPLOY_TOKEN_TOKEN in CI/CD variables (using values from group deploy token) and then just login with those:
before_script:
- echo $DEPLOY_TOKEN_TOKEN | docker login -u $DEPLOY_TOKEN_USERNAME --password-stdin $CI_DEPENDENCY_PROXY_SERVER
script:
- docker pull $CI_DEPENDENCY_PROXY_DIRECT_GROUP_IMAGE_PREFIX/alpine
Related
What's the best practice to grant application code (during local development) access to Google Cloud resources,
without generate and download a Service Account JSON Key File (setting GOOGLE_APPLICATION_CREDENTIALS env. variable)
without giving Google user direct access to resources
I have following 2 options I could potentially use:
gcloud auth application-default login --> together with --impersonate-service-account=SERVICE_ACCOUNT_EMAILS flag
OR, use gcloud auth application-default login normally --> authenticate with MY Google User Account to generate application default credentials ---> and update my application code as follow as in this reference code
from google.auth import impersonated_credentials
target_credentials = impersonated_credentials.Credentials(
source_credentials = google.auth.default(),
target_principal='SERVICE_ACCOUNT_EMAILS')
client = storage.Client(credentials=target_credentials)
Is there any pros and cons of each approach?
I want to read some files in one project existing in gitlab from the application via gitlab API. I create deploy token in the project through
settings -> Repository -> Deploy Tokens.
I then try
/api/v4/projects/MY_ID?private_token=MY_TOKEN
and
/api/v4/projects/MY_ID?access_token=MY_TOKEN
, and none of them work - Both return 401
Can't this deploy token use as an authentication token, and I have to create a new user to achieve it?
But the documentation describes that this deploy token is used for accessing this project, or?
You need to use a Personal Access Token not a Deploy Token. These are created from:
profile -> settings -> access tokens
And in the API request the ID you pass is the Project ID, eg:
curl "https://your-host/api/v4/projects/<project-id>?private_token=<your-private-token>"
To find the Project ID either go to the project page or query all projects you have access to, eg:
curl "https://your-host/api/v4/projects?private_token=<your-private-token>"
Cheers
S
TL;DR -- How do I override all internal passwords for GitLab (non-admin, non-external) users so that they cannot change their password and must use SAML to login?
We have an internal GitLab server that is set to authenticate via SAML to an AD which has MFA enabled (Azure reverse proxy).
Security has found out that users are setting a local password in GitLab and getting around MFA and logging locally into the server.
They're asking me to remove the login screen completely. I rather set an internal password for non-admin and non-external users, and somehow disable the password recovery (blocking email?). Is that possible?
This is the closest thing I found but no easy way to script that as far as I can see. https://docs.gitlab.com/ee/security/reset_root_password.html
I have a nodejs webapp with many users with a custom login process. I would like gitlab to accept that authentication and not force users to create a new app. What is the best way to accomplish this?
I would go for OAuth 2.0 Single Sign On (SSO). Below you can find the architecture diagram taken from here. As you can see the client is redirected to log in in the OAuth2 provider to get a valid token for authentication. The OAuth2 server must be configured for the application requesting access including the secret, the client id and the callback URL.
You can configure GitLab CE to sign in with almost any OAuth2 provider. Only be careful with the limitations:
It can only be used for Single Sign on, and will not provide any other access granted by any OAuth provider (importing projects or users, etc)
It only supports the Authorization Grant flow (most common for client-server applications, like GitLab)
It is not able to fetch user information from more than one URL
It has not been tested with user information formats other than JSON
You also need to configure your node js web application as an OAuth2 server. There are npm availables with the source code here.
Recommendation
I would install some open source Identity Management to separate the user management from your webapp, provides better integration with other third parties and forget about encryption and other stuff you need to take care in your webapp. There are multiple options such as KeyCloak for instance.
You have to define a dedicated user , and use the private_token of this user to login for ALL users that will use your application.
The restricition would imply all users will have the same rights ....
The other solution is to use the Private Token of the user at login. In this case , only the rights of these particular users will be used.
So, I thought I had this all working until I deployed to a new set of environments. I have a webapp that's authenticating just fine with multi-tenant WAAD users. But when I try to hit the webapp from an HttpClient after authenticating via AcquireTokenAsync I always get the login page as the result.
The only concrete thing I have to go in is the fact that the on-boarding process never seems to complete. The login prompt always asks me to give the WebApp and Native Client permissions.
I've triple checked client ids, tenants, app id urls, etc. Is there anything else to investigate? I hit this snag once before only for it to just start working :(
Edit #1: Webapp + api works just fine via the normal cookies, just seems to completely ignore the Bearer token I'm setting?
So it turns out I had set the Audience on the WindowsAzureActiveDirectoryBearer object incorrectly so the token was never valid...