Chef Manage Run History compromises sensitive data

Chef Infra (archive)
1

When adding the sensitive true attribute to an execute command the logs doesn’t display the error. But the command is fully displayed in the parameters (eye icon) for the step corresponding to the command in the run history.

2

Chef Manage run history always shows the name property. A workaround for you would be to explicitly use the command property instead of putting the command in the name property.

For example, switch from:

  execute 'knife user create venkman --password secret' do
    action :run
  end

(which would show up as execute | knife user create venkman --password secret | run)

To:

  execute 'create user' do
    command 'knife user create venkman --password secret'
    sensitive true
    action :run
  end

(which would show up as execute | create user | run)

You’d still want to use the sensitive property so that the values don’t show up in the error log if the resource fails.

1 Like
3

Hi @modille, Thanks for your quick answer.

Unfortunately, this is already what we’re doing in our recipe and it end up being displayed twice in the ‘Resource Parameters’ popup:
execute ‘Disable feature toggle…’ do
sensitive true
command 'command with sensitive information in line. '
end

4

Ahh, I see.

Possibly a defect they should consider fixing in Chef Manage?

I think the only workaround would be to wrap the execute resource in a custom resource, and change the command property to be wrapped in a Hash instead of a String.

I suggest this only because I noticed that Hash params show up in the Resource Parameters popup as:

[object Object]

so it’s effectively hidden.

A better solution would be a fix to Chef Manage.

5

Thanks for bringing this up! Because this defect could live in Chef client, Chef Manage, or Chef Reporting, I’ve created a Chef-internal ticket to track the problem and get it resolved.

If your need is pressing, please contact your Chef support representative. They can help you escalate this issue more quickly.

6

Thx Chip.
Can I have the ticket link.
Cause I will need to implement as soon as it’s released as per regulatory rules.

7

Hi YvangeIist! I see that you’ve got a ticket open with Chef Support around this issue as well. If you’re feeling you’re in a regulatory bind about this, please let the support team know that too.

I’ve linked this discourse thread to the ticket there so our internal eng teams have this additional context about what’s been tried.

Support is going to be the best place to go for resolution & tracking on your problem until it’s resolved.

8

Hello Chefs!!!

Just wanted to give an update to everyone on this thread. Im currently working on a solution for this issue, the place we are thinking to fix this is in chef-client - Once we have the code merged we will let y’all know.

The fix will be available on the next chef release but if you need to adopt it ASAP we will let you know the version it has it and you can install the package from our current channel. Keep in mind that this is not our stable version. :smile:

9

Chef Friends, the code to fix this security bridge has been merged!! :tada:

The version that will have this fix is v12.18.16 (and above) and you can use it as soon as you see it in the current channel.

10

Thanks. See you @ChefConf