Securing EventStore

EventStoreDB
#1

I am setting up EventStore under Windows, and currently I don’t have an option of putting it behind some proxy. I’d like to secure it as described in ACL (http://docs.geteventstore.com/server/3.1.0-pre/access-control-lists/) article, but my problem is that even after I’ve set all ACL’s to $admins, I still can get user information:

curl.exe -i http://localhost:2113/users/admin

HTTP/1.1 200 OK
Content-Length: 283
Content-Type: application/json; charset=utf-8
Server: Microsoft-HTTPAPI/2.0
Access-Control-Allow-Methods: GET, PUT, DELETE, OPTIONS
Access-Control-Allow-Headers: Content-Type, X-Requested-With, X-PINGOTHER, Authorization, ES-LongPoll, ES-ExpectedVersion, ES-EventId, ES-EventType, E
S-RequiresMaster, ES-HardDelete, ES-ResolveLinkTo, ES-ExpectedVersion
Access-Control-Allow-Origin: *
Access-Control-Expose-Headers: Location, ES-Position

{
“data”: {
“loginName”: “admin”,
“fullName”: “Event Store Administrator”,
“groups”: [
“$admins”
],
“dateLastUpdated”: “2015-05-22T11:50:59.67835+00:00”,
“disabled”: false
},
“success”: true,
“error”: “Success”,
“msgTypeId”: 113
}

``

Is there an option to completely hide this information?

– SR

#2

I dont understand what you are after?

You are worried that someone will view the metadata of the admin user?

#3

That should likely still be an authenticated request.

However that said, exposing ES to the internet is a very poor idea without a proxy in front of it.

#4

I'm trying to get as secure endpoint as that is possible. I don't know
all the details of public HTTP API, so it is hard for me to understand
whether this exposure could be harmful or not. If for all practical
purposes default ACL with all options set to $admins is good enough,
then I'll have to live with that.

-- SR

#5

Please walk through what you have done to set all acls to admins.

What about all other streams say if you have a /streams/foo does that
give a security error?

#6

I had created a new $settings with following content:

{
“$userStreamAcl” : {
“$r” : “$admins”,
“$w” : “$admins”,
“$d” : “$admins”,
“$mr” : “$admins”,
“$mw” : “$admins”
},
“$systemStreamAcl” : {
“$r” : “$admins”,
“$w” : “$admins”,
“$d” : “$admins”,
“$mr” : “$admins”,
“$mw” : “$admins”
}
}

``

(I can see the result in web UI)

If I try to get any arbitrary stream now I get a 401.

– SR

#7

I understand that that’s a bad idea for a production server, but now we are in early stages of development and that was easiest way.

– SR

#8

but /users/admin gives?

what does /streams/$user-admin give? I'm guessing a 401?

#9

I just verified,

user service is not checking any acls on gets of users. The underlying
streams do.

@james should it? I seem to remember the reason it isn't is it opens
up some hokey edge conditions

#10

curl.exe -i http://localhost:2113/users/admin

HTTP/1.1 200 OK

curl.exe -i http://localhost:2113/streams/$user-admin

HTTP/1.1 401 Unauthorized

(bodies omitted for brevity)