Roadmap question: Support for ACLs in ARI?

Is there anything on the roadmap to add ACLs to ARI? ARI is incredibly powerful, if an attacker was able to access this interface it looks like they could:

  • Load and unload modules
  • Enable/disable logging
  • Snoop on and record calls
  • Access recordings

The following also appears to be true:

  • Only basic password protection is available
  • Only network facing TCP sockets are available (No UNIX sockets)
  • No mutual TLS support
  • No way to limit which APIs a user can call

From a security perspective this is pretty scary, I’m not comfortable enabling this on a production server. Are there any plans to add ACL support so that apps can be limited to only the APIs & resources they need?

The obvious answer is to filter all REST requests through your own HTTP proxy. That you can implement whatever rules you like.

No, that is not a solution because it still leaves the highly powerful and loosely protected ARI interface listening on a network socket. It’s obviously possible to limit access by binding to and adding firewall rules, however for an interface this powerful it would be advantageous to limit what the API can do at the source, rather than rely on external controls which may be potentially bypassed.

I don’t want to have to put an external gate in front of the API, I want the API to be able to be configured into a safe configuration where I don’t need to.

I’m also not looking for stopgaps or workarounds, I know how to work around the issue. I want to know if it’s on the roadmap to add improved access controls to this very powerful API.

I am aware of noone working on such a thing. You can submit a feature request here[1].

[1] GitHub - asterisk/asterisk-feature-requests: A place to submit feature and improvement requests for the Asterisk project. Contains no code.

What happened to the fundamental Unix design principle of “do one thing and do it well”? ACLs should be handled by firewalls, not by telephony toolkits.

Yes, that is a solution, because you can use iptables/nftables to restrict access to that socket. Or stick the whole Asterisk process in a separate container.

As for “do one thing and do it well”, as Rob Pike has said, “Those days are dead and gone and the eulogy was delivered by Perl”.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.