Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support bearer auth (or custom headers) for repository URLs #1615

Open
marcelboldt opened this issue May 21, 2024 · 0 comments
Open

Support bearer auth (or custom headers) for repository URLs #1615

marcelboldt opened this issue May 21, 2024 · 0 comments

Comments

@marcelboldt
Copy link
Member

marcelboldt commented May 21, 2024

Feature request:

When using a custom artifactory such as jfrog - e.g. in an airgapped context - it is currently possible to work with basic authentication by embedding the credentials in the url. The same way sometimes works for a bearer token (even though discouraged) but sometimes it is necessary to add a http header instead. With jfrog this is an issue as their documentation recommends bearer token auth to be used in CICD pipelines, see https://jfrog.com/help/r/jfrog-platform-administration-documentation/authorization-headers.

This is especially useful for authenticating CI servers with Artifactory instead of using credentials, since you don't need to have a user defined in Artifactory

Various tasks (e.g. 'Download Remote Plugins' in roles/kafka_connect/tasks/connect_plugins.yml) use ansible.builtin.get_url which allows for custom header definition, there is just no way to configure the cp-ansible task. One could work around with an own playbook; for package manager a custom repofile could be provided. There are various other locations where there artifactory is used, working around these is problematic.

It would be preferable to have a variable like artifactory_bearer_token, or artifactory_custom_headers.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant