No view level.
For specific cards I create two separate views for different user types of its that complicated s Or use custom cards that have the ability to show/hide cards based on user context.
Edit: in fact ‘conditional card’ just got an update to support user as a condition…
Very much a pain and I would rather not. But it’s what I have to do to trust leaving an open panel in my hall with friends who like to test my stuff.
Aha! Thanks for this information. I haven’t used conditional cards before, but it seems quite useful
My kids can effortlessly locate smart plugs controlling the boiler through the logbook. This poses a risk of inadvertently disrupting our home’s systems, including disrupting our internet connection. I’d prefer selectively exposing Home Assistant devices through Apple HomeKit to a shared iOS device.
I’ve thought about this problem a bit. I’ve considered creating another instance of Home Assistant that can interact with the primary instance in a limited fashion. It’s pretty much the only option I see right now. Worst case they tank the secondary instance which would be backed up and not have access to anything important in the primary instance.
For that purpose it’s possible to build custom dashboard app which will only expose what the user need and use any security measures to protect the hardware from tempering.
Home Automation is always at risk of tempering by your guests but you trust them to not unmount your lighting so you can trust them to not temper your racks and your wallscreen.
Home Assistant wasn’t made for guests but you can easily use HA as a backend and only give your guests access to a remote or a wallscreen.
After all in many public places they are protecting the hardware, not the software.
On a kiosk without keyboard and no USB port you don’t have to disable ctrl+shit+del interacions.
Coffee machines are controlled by a touchscreen on a Windows software, the same is done for ATM and photo booth (and yes it does run Doom)
It feels odd to me that we have the ability to control which entities are exposed to voice assistants, but not which entities are exposed to users. It’s largely irrelevant whether this is technically RBAC. The spirit of what most people in this thread want for users is what was implemented for voice assistants. So it doesn’t have be called RBAC, but implementing “exposing entities to users” would satiate most people in this thread.
On the security front, this is the first paragraph of exposing devices:
To be able to control your devices over a voice command, you must expose your entities to Assist. This is to avoid that sensitive devices, such as locks and garage doors, can inadvertently be controlled by voice commands.
Sounds like that’s what most people in this thread are concerned about regarding security.
In any case, it seems like the solution to this thread already exists in HA. It just needs to be implemented for users.
There are so many use cases for that.
Also for the gardinier or home assistant, to unlock doors, or warter valve,…
So these users get rerstricted to special devices.
In my opinion the easiest way would be to have user groups and add users to these groups.
RBAC would be the right word, because this is how it is named in the industry.
The second option would be to lock a user to a dashboard, so he cant get to another dashboard.
However, this is needed really.
Thank you all for your support.
Kind regards
Antonio
User groups already exist in HA. The issue is that the default groups are basically Admin and User and the only way to add other groups is by YAML editing. The rest of the security subsystem for HA has never really been built out even though it’s been there for a few years now!
@joneshf does make a valid point that they put in the effort to doe entity exposure for voice assistants and the system would in theory be something that could also be leveraged for user exposure I would think. Getting that would be a big win for folks that want to provide access to untrusted people.
Mostly agree. One key difference, however… RBAC isn’t super hard to do right if it’s part of the original design. If it’s not, then yes, it’s hard, but the more other things that get developed before it gets designed in, the harder it gets. As such, I would argue that at least having an architectural plan for how RBAC will work and how it gets integrated into the code is the urgent ask so that we can get to a point where all future development is done with RBAC in mind and ideally baked in.
Fully agree. It’s strange that such an important set of features haven’t been implemented yet.
We definitely need a “Year of the User Management” 
It would be great to have RBAC implemented. For now, I have a workaround whereby I deploy a separate HA instance for my kids which connects to the main HA via the Remote-Home Assistant custom integration. It allows me to restrict the entities that are made available to the kids’ HA instance and because they are not given admin access, they can’t do any automations, etc. I haven’t tried but perhaps there could be multiples of this type of instances as well.
It is just mind boggling how such a well-known platform was released without basic security features like RBAC. How many years will it take to implement such a basic feature?!?
I have considered this for my situation many times, but don’t have much time to dedicate to it. I know my next question will depend greatly on each individual’s background and available hardware, but I run HAOS in a VM…wouldn’t be too bad to spin up another instance so…
Would you say the effort for doing this is:
A) Trivial
B) Takes a bit of work, but doable in a couple/few hours
C) Complex and takes the better part of a day or longer
thanks
Found this thread from another thread… figured I would post my thoughts here since it is recently active…
I just setup my 8yr old’s ipad for home assistant to tame/tone down the “Daddy can you make my lights blue, 2min later… green, 30sec later red…” and so on. Technology is great sometimes and other times requires a beer for reasons like this.
So, I did the user visibility for the “Kids Room” tab on my main dashboard, which works great! However, we now have the “Assist” option; and I gave this a quick test and all I can say is “Oh boy, this is gonna be fun!” As an example, Even with my Office Desk Light not being visible on her iPad, she is able to type in the response to Assist for: “Turn off Desk Light” and now I am typing this in the dark again! She just has to know the device name.
The options in the companion app let me “hide” other dashboards like energy, keymaster, and other critical things. But once she figures out what security by obscurity means she will know how to unhide these.
So, I am +1 on having a better RBAC system in place.
Kids are the future, so there will soon be no way to keep them from only getting in the cookie jar! They will someday run circles around us.
Reminder to everyone that kiosk-mode does what a lot of people in here are looking for.
Create a dashboard with only the entities you want a user to see and configure the device they use to use that dashboard by default. Then use kiosk-mode to hide the parts of the UI that you don’t want them to see (header, sidebar, more-info dialog options, etc). It offers a lot of control over what you can hide and whom you hide it for on a per-dashboard basis.
Here’s a simple config that I use to “lock down” a dashboard so they only can access directly what’s on it VIA the UI:
kiosk_mode:
non_admin_settings:
hide_header: true
hide_sidebar: true
hide_dialog_header_history: true
I already use Remote Home Assistant (where the main HA is actually the master of some remotes), so adding the main HA as a remote is trivial.
I run HA Core, so I just spun up an additional instance using the same python environment, but in your case, you might need to spin up a new HAOS/VM which will not have any integrations (apart from the Remote Home Assistant) or automations… really just using the frontend. Perhaps you might want to copy some existing cards over.
Probably a couple of hours.
Presumably, no matter how much you hide in the UI via workarounds, unless you can prevent the ability to type e or c anywhere on the dashboard - it definitely is not a suitable workaround.
I’m aware a staggering number of users don’t know about these shortcuts which have been around for a few years now, but - it would be very very easy for someone to stumble across them.
Those shortcuts are only enabled for admin users:
Not sure what you mean by “real reminder”, but I never said it was the “same thing”. I was offering people solutions instead of just complaints as you are.
Oh excellent, that’s good to know, otherwise people can get to parts of the system that they definitely should not be accessing.