How do I prevent the plugin from being disabled?

[bviktor]

So managing authorization is great and all, it's particularly a great idea via plugins (not), except for the fact that users can actually just disable the plugin right away. Yes, it's as easy as that.

docker plugin disable openpolicyagent/opa-docker-authz-v2:0.5

You can enforce the plugin via daemon.json or via systemd flag, but that will only cause dockerd to fail upon the next restart of the daemon. Until then, the user is absolutely free to do whatever they want. Namely, bind mount /, remove daemon.json and authz.rego, and that's it, all the AuthZ configuration is nuked.

So in essence, the value of the whole authorization process is exactly ZERO.

Am I missing something, or is it really impossible, even theoretically, to prevent users from doing whatever they want?

[bviktor]

https://stackoverflow.com/questions/54124227/how-to-prevent-other-users-from-stopping-removing-my-docker-container

[bviktor]

Running differently?

https://github.com/twistlock/authz

"Containerized" or standalone?

[tsandall]

@bviktor I haven't looked into whether an authorization plugin block docker plugin disable or not. If it's not possible then using the legacy method (mentioned in the README) would be the recommendation.

Namely, bind mount /, remove daemon.json and authz.rego, and that's it, all the AuthZ configuration is nuked.

That's certainly something you can stop with the auth/z plugin.

So, to answer your question, it seems like it's theoretically possible. It's worth mentioning this is less an issue with OPA or this plugin and more so a shortcoming of the Docker authorization framework.

[bviktor]

That's certainly something you can stop with the auth/z plugin.

Could you please elaborate how? I tried to look but I've found no info on this. I'd be happy with a full block, i.e. docker members cannot do any plugin command.

[tsandall]

Could you please elaborate how?

Ah, I see what you've described in #34 now. If users can symlink files then they trick any checks against the bind mounts...to deal with this we could improve the plugin code to resolve filesystem paths before querying OPA.

As far as blocking the plugin command goes, I'm not sure how this works. If you have the plugin running, you could look the logs to see if the authz checks occur for plugin commands. If the authz checks occur then you could write a relatively simple rule to whitelist who can run plugin commands.

[flixr]

Any updates here? @bviktor did you find any way to actually use this?

[bviktor]

Nope. I just keep hoping that no one figures it out in the company lol.

[flixr]

@bviktor I'm running opa-docker-authz as binary on the host started via systemd as explained in https://docs.docker.com/engine/extend/plugin_api/#systemd-socket-activation
That way it is not used as a managed plugin and hence can't be seen or disabled with docker plugin...

Don't have a solution for the symlink problem though... for now I deny all bind mounts starting with /...

[bviktor]

Hmm... sounds interesting. How do you obtain the binary, and what's your unit file ? Thanks in advance!

[flixr]

As I was too lazy to build it from source and the latest releases here on github are outdated, I just copied the binary from the ../docker/plugins/... dir..

my system units are just like described in the docker docs: /etc/systemd/system/opa-docker-authz.service

[Unit]
Description=A policy-enabled authorization plugin for Docker
Before=docker.service
After=network.target opa-docker-authz.socket
Requires=opa-docker-authz.socket docker.service

[Service]
ExecStart=/usr/local/bin/opa-docker-authz -policy-file /etc/docker/policies/authz.rego

[Install]
WantedBy=multi-user.target

and /etc/systemd/system/opa-docker-authz.socket

[Unit]
Description=A policy-enabled authorization plugin for Docker

[Socket]
ListenStream=/run/docker/plugins/opa-docker-authz.sock

[Install]
WantedBy=sockets.target

and of course I enabled it in daemon.json:

{
  "debug": true,
  "data-root": "/containerdata/docker",
  "authorization-plugins": ["opa-docker-authz"]
}

[bviktor]

Thanks, I'll take a look!

[bviktor]

How does one obtain the sources? 0.4 is the latest in the repo, but dockerhub is on 0.7 lol.

[bviktor]

The sources being unavailable is a different issue, the systemd activation trick actually solved this one for me too. Thanks a lot, @flixr ! One note: one has to systemctl enable opa-docker-authz.service && systemctl start opa-docker-authz.service, until then it won't work.

[anderseknert]

As far as blocking the plugin command goes, I'm not sure how this works. If you have the plugin running, you could look the logs to see if the authz checks occur for plugin commands. If the authz checks occur then you could write a relatively simple rule to whitelist who can run plugin commands.

Yep, just tried this when working on another issue. The relevant parts of the input would looks something like the below, when docker plugin disable <id> is called:

{
    "Method": "POST",
    "Path": "/v1.41/plugins/a21a4e016d28/disable",
    "PathArr": [
      "",
      "v1.41",
      "plugins",
      "a21a4e016d28",
      "disable"
    ],
    "PathPlain": "/v1.41/plugins/a21a4e016d28/disable"
}