Sent with ProtonMail Secure Email.
‐‐‐ Original Message ‐‐‐
On Sunday, January 12, 2020 10:48 PM, Greg Hudson wrote:
> On 1/12/20 2:01 PM, Laura Smith wrote:
>
> Since all of the permission bits are in uppercase, that line should
> grant no permissions to saltstack/admin. When I test
On 1/13/20 3:44 AM, Laura Smith wrote:
> Am aware of the list ordering requirement, and to that extent the ACL entry
> in question was quite deliberately placed at the top.
kadmind will continue on if the operation's target doesn't match the
entry's target. So if you have a later entry for, say,
‐‐‐ Original Message ‐‐‐
On Monday, January 13, 2020 4:19 PM, Greg Hudson wrote:
> On 1/13/20 3:44 AM, Laura Smith wrote:
>
> > Am aware of the list ordering requirement, and to that extent the ACL entry
> > in question was quite deliberately placed at the top.
>
> kadmind will continue
Laura,
If you can change the name of the principal Salt is using, then your
authorisation rules would not require one to deny it any other
permissions. The "admin" word isn't required to grant admin type
permissions.
For example if you changed it to "saltstack/salt.admin" you'd only
require,
sa
Kenny,
Sounds like a cunning plan ! Will go experiment.
Thanks
Laura
‐‐‐ Original Message ‐‐‐
On Monday, January 13, 2020 5:23 PM, Kenneth MacDonald
wrote:
> Laura,
>
> If you can change the name of the principal Salt is using, then your
> authorisation rules would not require one to