Graylog 3.0.0
The idea is to have the Web UI running on one server. The Backend running on another server. Using nginx between the two to control access to the /api route with some auth magic.
What I have found is that I can get a working solution except that any browser call to graylog/api will got the the Web UI host api pages.
I am coming to the conclusion that I cannot get those calls to route to the backend server.
Does anyone have any insights about this. I would greatly appreciate it.
but Graylog has build in authentication … why did you want to build additional authentication into it?
Basically what @jan said - if you have the need to control authentication from outside Graylog, interface with the API and have an external solution manage tokens/users with the proper access levels. Why bother trying to complicate matters?
I have been told that they cannot keep regular users from viewing API information. I don’t support it, I am trying to poc what the team wants.
I am not trying to add authentication. I am trying to control access to the api route.
Ben, They do control access now using JWT tokens. The problem is that API access doesn’t seem to be controlled whether the user is a regular user or an admin user.
Who is “they” 
And also, “I have been told” is a bit of a slim reason - if I listened to everyone telling me things I’d never get around to actually doing anything - as far as I am aware, Graylog’s API requires the use of tokens or Basic auth header before it will do anything.
Of course, if the team tried it out by using the api-browser, if someone saved their username/password combo in their browser, it will auto-fill the authentication info at the top of the page, and as such will execute every API request with that particular users’ privileges.
Unless I’m hilariously mistaken about what you meant…
Graylog having a API with JWT token auth is great @benvanstaveren @jan. I belive what @jryan is trying to ask is if there is a solution that allows a authenticated user to have limited access to API routes. Yes you all do a decent job of limiting API routes between Admin and Reader. But there are several routes a normal Reader user doesn’t need access to in my opinion. Such as the system/indices route. Why should a normal user be able to hit the API and see rotation/retention if they can’t see it in the frontend. Same goes for the system/jvm API route. Why does a normal user need to be able to see anything about the JVM? I understand that certain routes in system are needed in the frontend and can not be removed.
So coming back to @jryan original question. Do you all have any insights on a way that these calls can be limited? It is important to be limiting routes of a normal Reader user to the backend routes as many of them can leak information about other users/customers.
Graylog is Open Source - why not contribute to the product some more strict rules on the API? Or contribute with issues in Github that are specific about certain api endpoints. Raising your concerns in a way that the developers can work with it would also help.
The point is - all users would benefit if you integrate into the product, only you will benefit when you create a dedicated solution for you. Open Source is about sharing and not isolated development.
I agree that giving back through opensource software is important (and I have had several PR’s accepted, others in “review”). Overall I believe GL has made leaps and bounds with doing a better job at limiting API calls based on role. But the overall role structure is not ideal. Having a admin role is great. Having a reader role is great, but I believe the Reader role is a bit relaxed. Since everyone gets a reader role. There is no way to limit the default permissions that the reader has. Not all users need access to Input, Indexcluster, etc. Yes, I can go make a PR to apply these changes to GL and remove the Input role by default. But really when creating a role there should be a way to apply/remove permissions that are default.
@jryan use case is this… If someone who does not have development/code experience wants to limit API access, adding a proxy may be a more ideal/easier solution.
Overall you are saying that the end-users of your product need to be able to code to make the product more secure (by default). Where as not all of your end-users have the experience to do so. I would say however, that your average Graylog admin does have sysadmin/devops experience. So why not have a means to provide a solution that allows them to have a more strict grasp on the API? You can all have your recommend roles/permissions and if a user wants to limit routes (knowing it may break some of the frontend) then they can.
I’m happy to put this in a Github issue, but your community forum seemed more appropriate for a discussion.
I have the feeling that we are talking on the same topic but in different tracks.
It will already help to describe what is to open in someone eyes on the API - maybe there is a reason for that, maybe limiting something doesn’t came to the developers mind.
On the other hand you can define your own role via API and assign that to the users - this role can be limited in all ways the Graylog API provide. What is in my mind better than jumping between the two parts of the UI - as you might stop the UI in some points from working correctly.
Contribute does not always mean to provide code - giving another point of view is also contributing to a product.
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.
