Hello! I am working on upgrading Rancher within my company. I was wondering why as of 1.8.1, Rancher requires +w permissions on the settings.json file on launch and close. We usually chmod this so that users cannot make any changes to enable, disable settings that they shouldn’t be. I know the locked .plist file was introduced to lock down the Docker repositories that you can visit, but it appears that is all it can. Is there any suggestion for locking down the rest of the settings since it writes to that file anytime a user updates settings in the GUI?

guessing https://docs.rancherdesktop.io/getting-started/deployment/

Yeah I saw those new deployment profiles but it seems like if a user changes the settings.json or settings in the GUI, those override the default profile. The locked profile seems to supersede the settings.json but as far as I can tell, you can only lock on setting down?

the default yeah, but shouldn’t overwrite the Locked items.

And the only thing that can be locked is the allowed images/repositories?

nope? should be all settings though I have not tested them all

“The containerEngine.allowedImages settings are currently the only ones that can be locked”. That’s what the docs say so that’s why I was trying to do ACLs which used to work but now Rancher appears to need write permissions on the settings.json file

i don’t think they have a handy tool for windows yet, but you can use rdctl list-settings to dump everything

Yeah I was trying this on Mac first with a simple chmod on the settings.json, removing write access since it appears that allowed images is the only lockable setting.

The locked profile is only implemented for the Allowed Images settings in 1.8.1; the rest is waiting for corresponding support in the Preferences dialog

Yeah, it actually did. It would show like it was changed in the GUI but it wouldn’t change anything, and when Rancher would restart they would be reverted back. So essentially, it would show like it was changed but nothing did change and a restart of the app would remove the changes.

Interesting. But that was definitely no intentional behaviour, but a side-effect of how the write-failure was handled

Yeah I figured it wasn’t an intention. We were just trying to upgrade to the version with the allowed images since a user found a backdoor issue with the conf.d docker settings within the VM. It can be changed to add proxies, etc and those settings persist when the user restarts the app, essentially going through any controls.

wouldn’t the upstream proxy catch any distro level proxy shenanigans?

Nothing we can do will really prevent a malicious user from changing things; but it should be obvious to the well-intentioned employee that they are circumventing policy when they disable these mechanisms.

Yeah, understandable. We are trying to utilize the override.yaml in the meantime. We have policy around malicious actions but trying to lock down where ever possible.

I understand. It is like having a lock on the door. Nothing that can't be overcome with a bit of violence, but it will be obvious that you were not invited when you do that

We are just heavily regulated so the constant fight with our security folks is always a terrible time when we try to implement great products like Rancher

come on lock the laptop in a safe and drop it to the bottom of the bay. super secure

Like how Windows NT4 got a C2 security certification (only valid for configurations without a network card)

anything can be made secure with a bit of epoxy. usable… well you will adapt

Well thank you both @fast-garage-66093 and @wide-mechanic-33041! Appreciate the input and I look forward to the updates coming to Rancher!

Note that "Rancher" typically referes to "Rancher Manager", and this tool is called "Rancher Desktop". In hindsight this was an unfortunate naming decisions, but here we are...

Oh my apologies! just used to calling that from my day-to-day work. Will note that