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

Manage resources leaks API password in resource types #440

Open
Bouke opened this issue Aug 25, 2017 · 3 comments · May be fixed by #828 or #857
Open

Manage resources leaks API password in resource types #440

Bouke opened this issue Aug 25, 2017 · 3 comments · May be fixed by #828 or #857
Labels
enhancement New feature or request

Comments

@Bouke
Copy link

Bouke commented Aug 25, 2017

Currently the way zabbix_host is configured, it will inject $zabbix_api_pass into the resource with the property name zabbix_pass. This results in a password leak when puppet reports / resources can be inspected by third parties. At our setup, we run puppetboard without authentication. Other packages don't put clear text passwords in reports and resources, so this setup mostly works for us.

Affected Puppet, Ruby, OS and module versions/distributions

  • Puppet: 4.10.4
  • Ruby: ?
  • Distribution: Ubuntu 16.04
  • Module version: 4.1.3

How to reproduce (e.g Puppet code you use)

What are you seeing

When running the following PQL, the result includes the API credentials:

resources { type = "Zabbix_host" }

What behaviour did you expect instead

No passwords being logged.

Any additional information you'd like to impart

Other modules (e.g. puppetlabs/mongodb) write the credentials to a file (~/.mongorc.js). This way, there's no need to communicate the credentials through the resources.

@juniorsysadmin
Copy link
Member

An alternative might be to use the Sensitive Data type: https://docs.puppet.com/puppet/4.6/lang_data_sensitive.html

@juniorsysadmin juniorsysadmin added the enhancement New feature or request label Sep 29, 2017
@juniorsysadmin
Copy link
Member

ccing @roidelapluie for comment

@roidelapluie
Copy link
Member

Yes ; immediately we should use sensitive data type and in next major release switch to auth file.

@bdeferme bdeferme linked a pull request Jul 28, 2022 that will close this issue
@teluq-pbrideau teluq-pbrideau linked a pull request Dec 12, 2022 that will close this issue
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
3 participants