Broken Authorization in CI/CD
Play CI/CD Labs on this vulnerability with SecureFlag!
GitLab
GitLab, a robust platform for DevOps lifecycle management, integrates continuous integration and delivery (CI/CD) features along with source code management (SCM), offering various user permission levels to control access across different areas of the system.
By default, GitLab supports multiple access levels:
Guest
A Guest has limited access to a project. They can only create and read issues and view other parts of the repository if publicly available. This access level is commonly used for external stakeholders who only need limited involvement.
Reporter
Reporters have more access than Guests, allowing them to pull the repository, read it, and create issues. They cannot make changes to the repository but can view and comment on merge requests.
Developer
Developers can push code to branches and have permission to create merge requests. This level is often given to core team members who need to actively contribute to the project.
Maintainer
Maintainers hold significant control over the repository. They can push code to the repository, manage issues and merge requests, and make changes to project settings like enabling or disabling pipelines. They are commonly responsible for maintaining the project.
Owner
Owners have the highest level of permissions in a project. They can modify any setting and perform any action on the project, including removing it entirely. For group projects, the Owner role is typically reserved for users with administrative responsibilities.
Permissions Management
GitLab allows permissions to be set at the group and project levels. It’s essential to ensure users are assigned only the necessary level of access to maintain security and prevent unauthorized actions.
GitLab also includes fine-grained access control options, such as:
Protected Branches
Protected branches ensure that only users with the necessary permissions can push changes directly to the branch. Typically, only Maintainers and Owners have this ability. Developers and other users must submit merge requests for review before their changes can be included.
Approvals and Merge Requests
To maintain code quality and security, GitLab supports defining approval rules for merge requests. You can specify the number of approvers needed or require specific roles (like Maintainers) to approve a merge.
Security Dashboards and Permissions
In larger projects, GitLab offers security dashboards that provide an overview of vulnerabilities and risks in the codebase. Access to these dashboards is limited to certain roles, ensuring sensitive security information remains controlled.
Jenkins
Jenkins, a widely used continuous integration and continuous delivery (CI/CD) tool, offers multiple authorization models to manage user permissions.
By default, Jenkins supports a few different Authorization options:
Anyone can do anything
Everyone gets full control of Jenkins, including anonymous users. This setting is not secure and should not be used.
Legacy mode
As in Jenkins’ previous version, 1.164, users with an “admin” role have full control over the system. Other users, including anonymous ones, have read access. This setting is not secure and should not be used.
Logged-in users can do anything
Every logged-in user gets full control of Jenkins. This setting does not enforce authorization and should only be used in testing environments.
Matrix-based Security
This model allows you to specify the permissions for each user or group on a granular level. It’s highly customizable and suitable for large teams with varied roles.
As cons, the matrix can easily become complex with many users or groups, leading to misconfigurations or broken authorization.
Project-based Matrix Authorization Strategy
This allows the Matrix-based security to be defined for each project separately.
Role-based Authorization Strategy
This model allows you to define roles (like Admin, Developer, and QA) and assign specific permissions to these roles. Users can then be assigned one or more roles. This simplifies and allows scalable permission management.
Permissions
Granular permissions can be assigned when configuring Matrix-based or Role-based strategies. Permissions are provided by Jenkins core and plugins, and many of them can cause harm if misconfigured.
Some of the relevant Jenkins core permissions are:
- Overall: These permissions are granted globally rather than on individual objects. Overall/Administer assigns full control over the Jenkins instance and must be only used for administrative access. Overall/Read should also be avoided to prevent information disclosure.
- Job: Permissions on Jobs, such as running a build, configuring it, or reading their data. Jobs/Configure allows users to modify job configurations, potentially leading to code execution on the agent where the job runs. Jobs/Build can also be abused to launch builds and manipulate them with parameters. Jobs/Views and Jobs/Workspace privileges could also lead to sensitive data disclosure when assigned to the wrong user.
- Agent: These permissions regard the configuration of agents. Agent/Configure might be abused to redirect build jobs to malicious agents or change agents’ behavior to compromise builds.
- Credentials: Permissions on credentials managed by Jenkins. Credentials/View permit users to disclose credentials.
When setting up Jenkins permissions, it’s crucial to follow the principle of least privilege: only grant permissions that are absolutely necessary for a user’s role. Regularly review and audit permissions, especially for the more dangerous ones listed above, to ensure that your Jenkins environment remains secure.
References
Jenkins - Role-based Authorization