CodeConnections customize the OAuth app scopes
When creating a CodeConnections host for GitLab self-managed, a PAT is used to register an OAuth application on the GitLab instance. When a connection is created from that host and click "Update pending connection" to complete the OAuth handshake, the OAuth app requests broad scopes including write_repository.
These connections will be used by ArgoCD.
Two questions:
- Is it possible to customize the OAuth app scopes during connection setup to remove write_repository?
- Is it possible to restrict the connection to a specific repo rather than all repos ?
- Topics
- Developer Tools
- Language
- English
- Newest
- Most votes
- Most comments
See my comment to the other answer.
My recommendation is: Create a dedicated GitLab Service/Bot Account with access only to the specific repositories you want ArgoCD to see. Use this bot account to perform the "Update pending connection" handshake. This enforces the Principle of Least Privilege at the source.
Based on the available information about CodeConnections with GitLab self-managed, the connection setup process requires a GitLab personal access token with the api scoped-down permission to create the connection. However, the documentation does not indicate that you can customize the OAuth app scopes during the connection setup process to remove specific permissions like write_repository.
Regarding restricting the connection to a specific repository, the standard connection setup does not provide a mechanism to limit access to a single repository. The connection provides access based on the permissions of the GitLab account used to create it.
However, you can implement restrictions at the pipeline level. When configuring your pipeline, you can control trigger behavior by:
- Setting the pipeline to manual release only by configuring
"DetectChanges": "false" - Using trigger filters to specify which Git tags or branches should trigger the pipeline
- Specifying a particular source repository in your pipeline's source action configuration
For more granular access control following the principle of least privilege, you would need to configure fine-grained permissions at the IAM role level that your pipeline uses, ensuring the role only has the minimum permissions necessary for your specific use case. This approach limits what actions can be performed even if the connection itself has broader repository access.
The connection mechanism itself does not appear to support customizing OAuth scopes or restricting to a single repository during the initial setup process.
Sources
Connections for GitLab self-managed - AWS CodePipeline
Implementing Defense-in-Depth Security for AWS CodeBuild Pipelines | AWS Security Blog
Mostly correct, but with a key caveat for ArgoCD. • OAuth Scopes: Correct. AWS CodeConnections requests a hardcoded set of scopes. Manually restricting them in GitLab often breaks the connection status in AWS. • Repository Access: While the connection itself doesn't have a "repo selector," you can achieve this via GitLab. • ArgoCD Context: Since you are using ArgoCD (and not CodePipeline), the suggested IAM/Pipeline-level filters won't help.
Relevant content
- asked 2 years ago
- asked 2 years ago
It worked. Thank you Florian.