Add pillar support for vault policy assignment

[PhilippLemke]

What does this PR do?

SALT.MODULES.VAULT:

• Add pillar support for vault policy assignment

Previous Behavior

• Assignment of templated vault policies only via grains

New Behavior

• Assignment of templated vault policies via grains and pillar

Merge requirements satisfied?

• [ x] Docs
• [ x] Tests written/updated

Commits signed with GPG?

• no

[welcome]

Hi there! Welcome to the Salt Community! Thank you for making your first contribution. We have a lengthy process for issues and PRs. Someone from the Core Team will follow up as soon as possible. In the meantime, here’s some information that may help as you continue your Salt journey.
Please be sure to review our Code of Conduct. Also, check out some of our community resources including:

• Community Wiki
• Salt’s Contributor Guide
• Join our Community Slack
• IRC on LiberaChat
• Salt Project YouTube channel
• Salt Project Twitch channel

There are lots of ways to get involved in our community. Every month, there are around a dozen opportunities to meet with other contributors and the Salt Core team and collaborate in real time. The best way to keep track is by subscribing to the Salt Community Events Calendar.
If you have additional questions, email us at saltproject@vmware.com. We’re glad you’ve joined our community and look forward to doing awesome things with you!

[Ch3LL]

Will this also impact the vault execution module. I believe it should based off the code I read, but wanted to verify this since you are only editing the runner module.

[Ch3LL]

This will also require a changelog and I just had one clarifying question

[lkubb]

This approach has the problem that

a) either the token policies are not reliable (when only cached minion pillar data is used, as should be the case here) or
b) that it introduces a cyclic dependency while refreshing the pillar (when a token is requested to compile pillar values that rely on the vault execution module)

For context, see the linked (unmerged) PRs in #62674 (shameless plug: PR I wrote to overcome these issues, still needs a review :]).

[PhilippLemke]

This PR has a very limited scope -> only the policy assignment via pillar

a) either the token policies are not reliable (when only cached minion pillar data is used, as should be the case here) or
-> yes, it's necessary to keep track that the minion has current pillar data. But that is also important for other states, modules that rely on pillar data.

b) that it introduces a cyclic dependency while refreshing the pillar (when a token is requested to compile pillar values that rely on the vault execution module)
-> Indeed that's not handled in this PR. I think its comparable with the ext pillar.stack module, where you're also able to define pillars based on pillars from salt default pillar env.

PR #62674 looks very promising

[lkubb]

-> yes, it's necessary to keep track that the minion has current pillar data. But that is also important for other states, modules that rely on pillar data.

I agree that only relying on cached pillar data is sufficient in most cases. There have been several PRs with the exact same proposed change that were denied on the grounds of b) (e.g. #43288), but I am pretty sure the described cyclic dependency cannot happen if you only rely on salt.utils.minions.get_minion_data. It might have been a misunderstanding.

-> Indeed that's not handled in this PR. I think its comparable with the ext pillar.stack module, where you're also able to define pillars based on pillars from salt default pillar env.

This problem is specific to the vault implementation and is only present when you refresh the pillar during policy rendering:

minion requests token -> master renders policies -> refreshes pillar -> some pillar value uses the vault integration -> impersonating master requests token -> master renders policies -> refreshes pillar etc

[Ch3LL]

@PhilippLemke are you stating you want to close this one in favor of #62674?

[PhilippLemke]

Since #62674 addressed a wider scope, that's OK for me. Am Mo., 31. Okt. 2022 um 20:34 Uhr schrieb Megan Wilhite < ***@***.***>:

…

@PhilippLemke <https://github.com/PhilippLemke> are you stating you want to close this one in favor of #62674 <#62674>? — Reply to this email directly, view it on GitHub <#62889 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABS3HYGWDLUO5IN2MS7U6TLWGANNTANCNFSM6AAAAAARFC6CK4> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[Ch3LL]

Closing in favor of #62674