We recently released the first of many improvements to New Relic’s Role Based Access Control.
We want to make sure that you are able to make the most of these new features, so give the post a read, and then join us on July 31 at 10:30 am pacific / 1:30 pm Eastern when @That_Guy will answer all your RBAC questions for one hour! This Coffee Chat will take place in the New Relic Community Slack Channel.
July 31, 2017 Conversation from #coffee-chat Slack Channel
@Tori [9:06 AM]
Good morning, just put on a big pot of coffee.
@ saxon [10:27 AM]
This is the covfefe talk, right?
@hross [10:28 AM]
You got it @saxon! We’ll get started with some intros of our hosts in just a minute or two. In the meantime, feel free to share an intro of yourself and any questions you want to see addressed
@linds [10:35 AM]
Hey everybody! Just getting ready over here on the NR side!
My name is Lindsay, I moderate our amazing customer community!
Today we have Darrel, our brilliant SME who is ready to chat with you all about RBAC!
This is our very first coffee chat so be stoked that you are helping us make history
We wanted some real time opportunities to hear from you, our customers and friends! So thanks for joining us on Slack this time.
@That_Guy/ darrel [10:41 AM]
Greetings everyone!! I have been working closely with our development team on this project and look forward to answering your questions.
@ rgindes [10:43 AM]
so i’ve been playing around with the rbac stuff and i think a lot of it is cool, wondering if there are any plans to create some kind of “group” logic
basically like a template really — like, define out some group that has A,B,C restrictions and X,Y,Z permissions, and then tie users to that group
and actually that ties in with another question i have, which is — generally speaking — how much more granular are you planning on going with permissions? like maybe the ability to allow modifications but not deletions, or only allow actions on certain subsets of things
@That_Guy/ darrel [10:47 AM]
Thanks @rgindes. Most of our focus initially is on more granular permissioning on a user by user basis. However, the team is actively looking at solutions that will fit a more complex enterprise structure. As we expand on the current functionality I do encourage you to highlight your specific requirements on our forum as this will ensure they have visibility with our product design team.
@ rgindes [10:47 AM]
because i guess my original question doesn’t have a great use case behind it with RBAC as it is now — its not really a big lift to check 3-4 boxes or whatever it ends up being
ah cool yeah thats what i was definitely thinking after i asked that — if i end up saying that these 10 people are restricted but can get into infrastructure and insights, or what-have-you, that’s not really a crazy amount of clicks
but if the permissions get a lot more granular i can see it being really helpful to drag people into a group that’s already predefined what everyone in that group can and can’t do
@That_Guy/ darrel [10:50 AM]
We are definitely looking to increasing the granularity as well. How minute these options will be is yet to be determined but we do want to build out tooling that will allow for complex organizations.
@ rgindes [10:51 AM]
awesome — i’m also thinking about something that may not be super-RBAC related, which is the ability to define teams of users, that’s a big thing for us because of how our org is set up… would be nice to define out the permissions a given team in our org has for rbac but also for, like, usage reporting based on groups
but again that last thing might not be completely related to this, not to derail the conversation
@that_guy/ darrel [10:53 AM]
I really hate to sound like a broken record but I can not stress enough how ensuring that your use case is documented in the feature ideas category on the OTC is . A lot of the future functionality potential will be determined off these ideas posted.
@ rgindes [10:53 AM]
yeah makes perfect sense! i’ll make sure we’re up to date on funneling our stuff through the right channels
@that_guy/ darrel [10:54 AM]
Not a derail at all, since a lot of this functionality is very closely related.
@ rgindes [10:54 AM]
also if other folks want to jump in please don’t allow me to monopolize the whole chat, lol
@ saxon [10:56 AM]
to be honest I’m not sure what roles we would give to people and why we’d need to restrict certain things
@ saxon [10:57 AM]
we’re not as big as Gannett (hi local Atlanta company)
3 replies Last reply today at 11:05 AM View thread
and right now we have everybody with user permissions so they can see the errors page
which is mostly what we use NewRelic for
there’s a few of us who dig into server metrics
but it’s not something we’ve needed to hide from anyone
are there certain things you’d suggest locking down or why we might want to do so?
@that_guy/ darrel [11:00 AM]
Really it will depend on the structure of your organization. In some cases a user or admin (if you need to manage utility such as alerts) level will be all you need. However, moving forward, if you start bringing in contractors for specific projects you may find that you want to start imposing limits on what can be accomplished. This is what the RBAC project is all about. Providing tools for a diverse environment.
@ rgindes [11:01 AM]
oh man sorry to step on you @saxon but it just made me think — something that would be really cool to lock down is to have some control on the actual data people can see, specifically in insights (might be something you can do already)
but for example if we want to flow ad revenue data through new relic, we don’t want everyone to be able to see that
@That_Guy/ darrel [11:04 AM] @rgindes so far we are not at that level of control. While a restricted user will only have ‘view’ capabilities across products , we do not currently allow scoping dat to user level. This is a great idea though and with the versatility of Insights I can see how this could be desired.
@ rgindes [11:04 AM]
so actually being able to, say, label certain data or certain sources, and then controlling on that, would be cool
@linds [11:05 AM] furiously taking notes on all of Rob’s great ideas
@ rgindes [11:05 AM]
oh yeah totally — i figured that might be kind of an off-the-wall ask but that’s something we could really use — we could even do cool stuff then like scoping various systems only to the teams that own them, so when they start running queries they don’t have to filter as much
they could say stuff like, give me the health of all my load balancers, without worrying if some other teams’ load balancers they dont care about will show up
(we accomplish this with amazon tagging right now but it would be helpful to be able to arbitrarily carve out groups of stuff in new relic)
@That_Guy/ darrel [11:07 AM]
I agree, That would be awesome, but building that level of data scoping would be a large exciting project.
@ rgindes [11:07 AM]
oh absolutely, im assuming this is a bigger ask than i even think it is
@linds [11:07 AM]
Love how invested you are in the future of our products!
@ rgindes [11:07 AM]
but, big picture, rbac for sources/data itself, would be really cool
lol … yeah, we’re, you know, loud
but yeah sorry i took that off in a wild direction, seeing @saxon ask the question about what you
…er hit enter too early… what you’d want to see restricted, just made me think of it
@That_Guy/ darrel [11:08 AM]
Loud but full of great ideas. And we truly love hearing em.
@ rgindes [11:09 AM]
glad to hear it!
so i only have one other thing i was thinking of which is that i really like the UX — i like that it updates and shows you what the changes you’re making will apply to, that will save people like me who mess up everything all the time
so i definitely hope that sort of flow stays around as you build it out more — you’d be shocked at how many tools we use that don’t have that kind of concept, so you add some permission to some group or person, and it doesn’t effect them the way you think it would — this makes it really clear
@That_Guy/ darrel [11:16 AM]
That is great to hear, as we began building out the add-on roles it became obvious that a lot of the functionality assigned with the base roles was not clearly outlined. We wanted to ensure that all the capabilities associated with a role were clearly defined in our documentation and in the actual UX. I am happy we succeeded. Our UX team will really enjoy the feedback.
Has everyone else found the add-on roles useful in your environments?
@ lesm [11:21 AM]
haven’t used the add-on roles yet but I agree that the capabilities preview is great
@That_Guy/ darrel [11:30 AM]
When we began this project we truly wanted to ensure that all our products began following a similar user capabilities flow. For example, A restricted user only having ‘view’ access to any product being used. This was in stark contrast to our previous organization, where a users base role could have different utility based on the New Relic product in use. With this baseline parity in place across all New Relic products we hope that all our customers will be able to fit us seamlessly into their organization structure.
@linds [11:30 AM]
Any last minute questions for @darrel before we wrap?
@That_Guy/ darrel [11:31 AM]
wow, this time has flow by. I really appreciate you all showing up.