Hi Cyril,
On Sat, Jun 26, 2010 at 10:29:45PM +0200, Cyril Bonté wrote:
> > This feature is appealing, however for security concerns, I've always
> > wanted to stick to a "read-only" access to the web interface. It's
> > too easy to get caught with an accessible interface on the net with
> > people who are able to change parameters. And I've observed such
> > unexpected accesses several times now.
>
> Oh yes, I can't count the number of servers where I've seen public access to
> the mod_proxy_balancer and mod_jk pages.
Not only that, but also haproxy stats pages behind reverse proxies
that were supposed to block them and which don't completely due to
rewrite rules.
> > But on the other hand, I know that several people are interested with
> > such a feature. So I think that the better solution is to start the
> > debate here. One idea could be that authentication with crypted
> > passwords is absolutely mandatory to enable such features. Maybe
> > other persons will have other ideas.
>
> Some configurations may want to have no authentication and set restriction
> for
> some other rules. Maybe a keyword with a mandatory condition can answer to
> all
> needs.
You're probably right. I'm thinking about test platforms where
nobody wants any password for example.
> Example :
> stats admin if <cond>
>
> In this case, I don't think "unless" is a good idea, but I may be wrong.
For compatibility with other rules, it would still be preferable
that if/unless both work. Anyway, if the rule is wrong, the guy
doesn't get his stats, so this is quickly noticed :-)
> This will let people choose the restriction by themselves :
> - only allow a subnet
> - only enable administration functions to userlists/groups
> - make administration totally public, assuming they know what they do and
> what
> they want, by declaring a condition that clearly say that.
> - ...
>
> This is just an idea ;)
This idea goes in the right direction. However, right now all
"stats" statements can be set in defaults section and automatically
enable stats (which was a very bad idea from the beginning since it
causes confusion between frontends and backends). So I think that
adding this feature might be the opportunity to clean up that mess
and refer to proper services, paving the way to other future services
(cli, etc...). A good solution would be not to extend the current
"stats" keyword and create a new "service" section which could be
used approximately like this :
service user-stats
handler stats
service admin-stats
handler stats
stats auth XXX
stats level admin
...
frontend public
use-service user-stats if { url_beg /stats }
frontend private
use-service admin-stats if { url_beg /stats } && { src 192.168.0.0/16 }
Later we could then migrate the current stats CLI to a similar service,
create new services and bind them to TCP ports or Unix sockets, and use
them as we want. This will be especially important later when we one day
support SSL, because we'll be able to describe the service at the end of
the stack.
Now if we go back to reality and consider what can easily be done right
now without changing everything, then probably we'd just have the
"stats level admin" statement, we should refuse it in defaults section,
and we should emit a big warning in the logs if there's no auth, or even
refuse to start, and only the redesign will allow that to work.
Regards,
Willy
