Security concern: Aptly API access control with runner tags

Out of curiosity, I noticed something that might be a security concern. It seems that any CI job using the “aptly” runner tag can access our Aptly API endpoint without authentication.

My question is: if someone who can create CI jobs runs a command like:

curl -X DELETE http://[aptly home url]/api/repos/[repo-name]

from a job tagged with aptly, would that actually succeed?

There are a few parts to this. Ideally only maintainers would have seats on the project’s GitLab subscription. This would enforce that work being done on any project would use the “forked” model and would result in merge requests not having pipelines run automatically. Maintainers would manually trigger a pipeline run as part of the review process, after ensuring no malicious code was included in the review. There are also opportunities for additional settings and checks to ensure things are protected. As a whole this would ensure a malicious actor would not be able to do such actions. However, to answer your question, we need to review and implement further protections to ensure this security concern is addressed.

1 Like

The concern is valid however there are several things that will reduce the potential damage. Each aptly operation generates a snapshot and previous states can easily be restored. Higher level objects like repositories and publishes cannot be deleted if there are dependent snapshots.

Yes someone could write a script to discover and delete all packages, snapshots, publishes and repositories but it would be hard to hide from a maintainer. Even if successful, the aptly database is backed up daily and can be restored.

1 Like

This topic was automatically closed 21 days after the last reply. New replies are no longer allowed.