Hey everyone!
Please summit your questions for the webinar Q/A here prior to start of the webinar.
You can register to attend the live webinar at:
Will also be using this topic for follow-up Q/A or discussion to keep the conversation going after the live webinar is over.
Hey!
So we had a good turn out today, and I wanted to address a couple of Q/A questions in more detail.
First up a question about how the new experimental prune feature works.
…it is possible to specify multiple file as input for the prune command.
As of now, no, this is probably a bug. As a reminder prune this is an alpha feature so this is agreat time to file bug reports to help solidify this feature.
I’ve file this issue so hopefully this will get fixed for the next release.
Okay, second question that came up was about granularity of RBAC controls.
I’m going to re-phrase the question a bit but the gist is:
can you setup RBAC to give access to edit specific checks or just the check command across multiple checks,
The answer is a partial yes. Yes you can give granular control to edit a single resource such as a check, but no, you can’t setup a role that you can only grant editting to specific attributes of a resource.
So the be clear:
YES: you can construct a role to limit editting of an existing check resource
NO: you cannot construct a role to limit editting of just check command attribute inside check resources
And as Caleb mentioned in the webinar. there’s some thought being put into extended the RBAC rules to allow for label selection, so you can more easily group resources under a role so that you don’t have to explicitly list each resource. Stay tuned on that.
In the meantime want to show everyone an example of an RBAC configuration that can be used to edit an existing check.
First I’m going to create a user named ‘limited-user’
sensuctl user create limited-user --interactive
Now I want to create a a dedicated role snd role-binding that will allow this user to only edit the check named test-check
type: Role
api_version: core/v2
metadata:
name: test-check-edit
spec:
rules:
- resource_names:
- test-check
resources:
- checks
verbs:
- get
- list
- update
---
type: RoleBinding
api_version: core/v2
metadata:
name: test-check-edit
spec:
role_ref:
name: test-check-edit
type: Role
subjects:
- name: limited-user
type: User
Now if you configure sensuctl for limited-user the limited-user won’t be able to list the checks but they will be able to see the test-check and edit it
sensuctl config view
=== Active Configuration
API URL: http://carbon:8080
Namespace: prune
Format: tabular
Username: limited-user
JWT Expiration Timestamp: 1587075805
sensuctl check list
Error: unauthorized to perform action
sensuctl check info test-check
=== test-check
Name: test-check
Interval: 10
Command: echo "this is a limited test"
Cron:
Timeout: 0
TTL: 0
Subscriptions: test
Handlers:
Runtime Assets:
Hooks:
Publish?: false
Stdin?: false
Proxy Entity Name:
Namespace: prune
Metric Format:
Metric Handlers:
I can also use sensuctl edit check test-check to interactively update the check or use the API.
You can further expand on that role by adding rules to open up more of the api. Specifically, its a good idea to give users the ability to list all the checks, which will help with the web-ui. But I wanted to give you an example of an extremely locked down RBAC rule that gives access to edit exactly a single check to an example of using Sensu RBAC at the most granular level. But because the Sensu Role allows for multiple rules it’s easy to start with a viewer role that has the necessary get and list verbs for all resources in place and then add additional rules to grant specific resource editting rules like above.
If y’all missed the webinar (or would like a recap), here’s the video:
And here’s a list of some of the resources we mention in the webinar: