Issue #3521
Updated by ttereshc almost 6 years ago
Importers and distributors have a "last_override_config" object which is exposed via the API. In several cases, secrets are passed into override_config when triggering a task. For example, in yum importer there's ssl_client_key and in docker importer there's basic_auth_password. If these config items are given, they're stored in last_override_config and then become readable to all users with read access on the distributor/importer. This makes usage of those config items quite dangerous as one can't pass these secrets into the API for a sync without also considering which users have read access on the objects, and whether it's OK to expose the secret to those users. Or more likely, one would fail to consider this, and thus would build tools/workflows which expose the secrets without realizing it. That latter scenario is exactly what I'm faced with now, because it has always been established procedure that our Pulp installations internally have widely shared read-only accounts, allowing everyone to freely data mine / build applications on top of our Pulp without administrative hassle. Due to realization of this issue, that's now under threat and we may be forced to make the system less convenient. Solution: Can you please consider how this can be improved? Some ideas which come to mind: - Document this risk and link to that from wherever override_config accepts a secret - Document a recommended setup for "read-only" accounts, e.g. perhaps it can block access to importers/distributors ? - Don't keep the secrets in the DB at all - Keep the secrets in the DB but don't render them in the API
.