curang*user* experience* - conf.splunk.com · agenda! problem*statement!...
TRANSCRIPT
Copyright © 2014 Splunk Inc.
Sanford Owings Principal Consultant, Splunk
Cura@ng User Experience
Disclaimer
2
During the course of this presenta@on, we may make forward-‐looking statements regarding future events or the expected performance of the company. We cau@on you that such statements reflect our current expecta@ons and
es@mates based on factors currently known to us and that actual events or results could differ materially. For important factors that may cause actual results to differ from those contained in our forward-‐looking statements,
please review our filings with the SEC. The forward-‐looking statements made in the this presenta@on are being made as of the @me and date of its live presenta@on. If reviewed aPer its live presenta@on, this presenta@on may not contain current or accurate informa@on. We do not assume any obliga@on to update any forward-‐looking statements we may make. In addi@on, any informa@on about our roadmap outlines our general product direc@on and is subject to change at any @me without no@ce. It is for informa@onal purposes only, and shall not be incorporated into any contract or other commitment. Splunk undertakes no obliga@on either to develop the features or func@onality described or to
include any such feature or func@onality in a future release.
Agenda
! Problem Statement ! Controlling What Users Can See ! Corralling^W Guiding Users to Their Data ! Smoothing Workflow ! Profit!
3
What’s the Issue?
4
Business is Good!
5
! Increased adop@on of Splunk has brought a wider variety of users to the Splunk UI in search of the virtues of Big Data
Why Is That a Problem?
6
! Poorly wri\en searches can impair other user’s ability to use the system
! Search language can be hard to pick up ! These “business” users may not have the @me to sort through events, instead they want to see results – Splunk centers of exper@se may be burdened with dashboard/search
requests by users
How to Mi@gate These Factors?
7
! Use roles to dis/allow access to data ! Provide some curated content ! Keep users in a walled garden
Scenario
8
Sample Environment firewall
weblogs Windows
bro
msad
Sample Environment firewall
weblogs Windows
bro
msad
Windows Admins
Web Admins Network Admins
Managers
Scenario Descrip@on
11
! Windows administrators should default to seeing Windows events – Ok to see msad index, but not by default – Windows Infrastructure app installed
! Web admins should default to seeing web events – Some summary dashboards and forms are available
! Managers should ONLY see web events – Preferably no access to search bar, summary dashboards only
! Network admins need to search bro, msad, and firewall indexes by default – Network admins can also see all other indexes
Building Blocks – Roles
12
Roles
13
! Roles are a handle for referring to a user/group of users ! Access permissions applied to roles ! User capabili@es defined by roles ! Can place limits on a user’s use of resources
Making Use of Roles
14
! Define the role – Set limits, capabili@es and access
! Apply access rules on applica@on content ! Note that most roles inherit “user”, which has ability to search all indexes!
! A user’s capabili@es are the union of all of their access permissions
Protec@ng Data
15
Sample Environment firewall
weblogs Windows
bro
msad
Windows Admins
Web Admins Network Admins
Managers
win_admins web_users net_admins
Splunk UI Role Management (Indexes)
17
Scenario Roles (authorize.conf)
18
[role_win_admins]!importRoles = user!srchIndexesAllowed = windows;msad!srchIndexesDefault = windows!
[role_net_admins]!importRoles = user!srchIndexesAllowed = *!srchIndexesDefault = bro;firewall;msad!
[role_web_users]!importRoles = user!srchIndexesAllowed = weblogs!srchIndexesDefault = weblogs!
Web Admins Managers
Windows Admins
Network Admins
Validate Accesses
19
! Who can see what? ! | rest /services/authoriza@on/roles ! imported_srchIndexesAllowed vs. srchIndexesAllowed ! Check out governance app ! h\p://apps.splunk.com/app/1866
Search Results – REST API (roles)
20
Fix Inherited Role
21
We can clone the user role and base the capabili@es off of that, or simply adjust it so that it doesn’t confer too much privilege
Desired Constraints
22
Cura@ng Content
23
Constraining Users != Bad ! Guiding users to the content they want is not a bad thing – saves everybody @me
! Simple dashboards and form searches can go a long way to giving users what they’re looking for
! “index=*” on a constrained set is not going to overwhelm indexers (as much)
! Consider building a data model, allowing users to pivot
“How Do I Find…?”
25
! Start a search, save as … Dashboard Panel
! Avoids icky search – admin writes a reasonable one, reuses for user content
“Now What About …?”
26
! Instead of rewri@ng searches, allow the user to drive with input ! Convert search to a form (Edit Panels -‐> Add Input)
Search string may have to be adjusted to account for use of tokens
“Where’s That Form…?”
27
! Modify the naviga@on menu to make custom content easier for users to find
! Sewngs > User Interface > Naviga@on Menus
Walled Garden Sowing Content
28
Linking Shared Content Together
29
! Create a separate app (namespace) ! Users looking for this content can find it all in one place (UI nav)
! Apps > Manage Apps > Create app
Migrate or Create Content for App
30
! Exis@ng dashboards/views can be relocated to the new app
! Other content can be moved as well
De-‐clu\er
31
! App menu now contains new content ! Apps geared towards admins/ superusers s@ll visible to everyone
! Set app permissions
Your applica@on name here
Control App Viewership
32
! Permissions on an app govern whether it even shows up
! Many apps default to “Read by Everyone”
The Walls Go Up….
33
! Reduce confusion – By limi@ng access to apps, the user is guided to their content – Some apps may not work without special access to data, so dashboards
would be blank
! S@ll requires that user select the target app
Welcome to the Garden
34
! Role-‐based way to set “landing” app? ! Saves users trouble of selec@ng app menu
– Some sites may even hide the app menu, making direct placement into the app key
! Set at role level ! Sewngs > Access Control > Roles
Advanced Considera@ons
35
Mul@ple Search Heads
36
! Role enforcement is done by the search head – Trust rela@onship with indexer is host-‐based!
! Keep role defini@ons (and membership) consistent! – Ensure that a user can’t see data they shouldn’t simply by logging in to a
different search head
! authorize.conf contains role mappings, share with DS / Puppet / Chef, etc.
LDAP/AD Integra@on ! Map LDAP / AD group membership to Splunk roles
– Creden@als in LDAP ! Another way to keep group / role membership consistent ! Documenta@on
– h\p://docs.splunk.com/Documenta@on/Splunk/latest/admin/Authen@ca@onconf
! Splunk Blog – h\p://blogs.splunk.com/2009/08/13/ldap-‐auth-‐configura@on-‐@ps/
Summary
Wrapping Up ! Restric@ng access to data requires a separate index, and separate roles
! Providing a basic search in the shape of a form helps users find data without being bogged down in Splunk search language – Can insulate against “expensive” searches
! Keeping users within specific apps can help guide them to data more quickly – Less confusion about what app to select, where to find the dashboard(s) – Group like content together, set as default app
Resources – Splunk Docs
40
! h\p://docs.splunk.com/Documenta@on/Splunk/latest/Admin/Authorizeconf (authorize.conf – roles)
! h\p://docs.splunk.com/Documenta@on/Splunk/latest/Admin/Defaultmetaconf (default.meta, local.meta – permissions)
! h\p://docs.splunk.com/Documenta@on/Splunk/latest/Admin/ConfigureSplunktoopeninanapp (default applica@on)
Resource – Splunk App
41
! (Data) Governance app – h\p://apps.splunk.com/app/1866 – Who can see which indexes? – What capabili@es do users have? – What apps do users have visibility to?
THANK YOU