You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Chef: 12.21.4 (yes, we know it’s dated. I hope this doesn’t affect this, but from what I can tell (see "Additional Information"), it should not)
Platform Details
Linux: Ubuntu 16.04 and Debian testing
Scenario:
We were previously using the 2.x line of the cookbook. We have multiple chef servers. The master repository from which chef servers are initialised does not know all nodes, and thus secrets cannot be encrypted for all nodes there using knife. We encrypt the vault items for a user which is common on all chef-servers.
We have a provisioning recipe which is run on the chef server. It uses chef_vault_secret to update the search query for the nodes on the chef server and re-encrypt the databag item. The existing item can be decrypted using the common user I mentioned above. It is then encrypted for all nodes which need it. The value stored in the item is left unchanged here.
Steps to Reproduce:
Create vault item foo in data bag test with the contents {"id": "foo", "key": "value"}. Set admin (or whatever user, adapt the recipe below otherwise) as admin and don’t add any clients.
The vault item should be re-encrypted for the clients given in the search expression.
Actual Result:
The vault item is not re-encrypted for the clients, but instead the resource claims to be (up to date).
Additional Information
I think the cause of this is that with the migration to LWRP, desired_state: false was added to the admins, clients and search properties. I think this should be removed, because change to any of those effectively requires re-encryption of the vault item.
Alternatively, I suggest to add a chef_vault_reencrypt resource (or something similiar) which allows to do this.
The text was updated successfully, but these errors were encountered:
Hey There
It looks like this is the first issue you've filed against the chef-cookbooks project. I'm here to offer you a bit of extra help to make sure we can quickly get back to you.
Make sure you've filled out all the fields in our issue template. Make sure you've provided us with the version of chef-client you're running, your operating system and the version of the cookbook. If you're not using the most up to date version of the cookbook then please make sure to update first. Lots of things change between versions even if you're issue isn't listed in the changelog. Finally please give us a detailed description of the issue you're having. The more we know about what you're trying to do, what actually happens, and how you can reproduce the problem, the better.
If you're looking for more immediate troubleshooting help make sure to check out #general on the Chef Community Slack. There's plenty of folks there willing to lend a helping hand. Thanks for the first issue. We hope we can get back to you soon with a solution.
horazont
changed the title
Change of search query does not re-encrypt vault item
Change of client search query or admins does not re-encrypt vault item
Aug 6, 2018
Cookbook version
3.1.0
Chef-client version
Chef: 12.21.4 (yes, we know it’s dated. I hope this doesn’t affect this, but from what I can tell (see "Additional Information"), it should not)
Platform Details
Linux: Ubuntu 16.04 and Debian testing
Scenario:
We were previously using the 2.x line of the cookbook. We have multiple chef servers. The master repository from which chef servers are initialised does not know all nodes, and thus secrets cannot be encrypted for all nodes there using knife. We encrypt the vault items for a user which is common on all chef-servers.
We have a provisioning recipe which is run on the chef server. It uses
chef_vault_secret
to update the search query for the nodes on the chef server and re-encrypt the databag item. The existing item can be decrypted using the common user I mentioned above. It is then encrypted for all nodes which need it. The value stored in the item is left unchanged here.Steps to Reproduce:
Create vault item
foo
in data bagtest
with the contents{"id": "foo", "key": "value"}
. Setadmin
(or whatever user, adapt the recipe below otherwise) as admin and don’t add any clients.Execute the following recipe:
Expected Result:
The vault item should be re-encrypted for the clients given in the search expression.
Actual Result:
The vault item is not re-encrypted for the clients, but instead the resource claims to be
(up to date)
.Additional Information
I think the cause of this is that with the migration to LWRP,
desired_state: false
was added to theadmins
,clients
andsearch
properties. I think this should be removed, because change to any of those effectively requires re-encryption of the vault item.Alternatively, I suggest to add a chef_vault_reencrypt resource (or something similiar) which allows to do this.
The text was updated successfully, but these errors were encountered: