# API public accessible **URL:** \ **Category:** Icinga 2\ **Tags:** api, icinga2\ **Created:** [November 6, 2020, 1:24am UTC](https://community.icinga.com/t/api-public-accessible/5981 "2020-11-06T01:24:54Z")\ **Posts on this page:** 7\ **Page:** 1
**Author:** ![ronanlucio](https://community.icinga.com/letter_avatar_proxy/v4/letter/r/b4bc9f/32.png) [@ronanlucio](https://community.icinga.com/u/ronanlucio)\ **Post date:** [November 6, 2020, 1:24am UTC](https://community.icinga.com/t/api-public-accessible/5981/1 "2020-11-06T01:24:54Z")
Hi, I need a publicly accessible API to use for passive checks. So I’m wondering if: - Can I make the master server public accessible (only port 6556 over HTTPS)? Is it OK? - Or should I launch a satellite for public passive check and make it send data to master server? NOTE: For this case, I’d set user permissions as: `permissions = ["actions/process-check-result"]` Thank you, ---
**Author:** ![dgoetz](https://community.icinga.com/user_avatar/community.icinga.com/dgoetz/32/917_2.png) [@dgoetz](https://community.icinga.com/u/dgoetz)\ **Post date:** [November 6, 2020, 7:42am UTC](https://community.icinga.com/t/api-public-accessible/5981/2 "2020-11-06T07:42:21Z")
My first question would always be how publicly is it needed. If you can limit it to some IP addresses it could reduce attackable surface very much. It should be much harder to get a pre-shared key instead of a password so for authentication I would use a client\_cn and multiple users if possible and not to much overhead. Best way would be if the key for this client certificate never leaves the system, so generate key and certificate request on the sending system, send certificate request to the master, sign it and send certificate back. But still if authentication is well protected and secure, it opens up denial of service attacks. For this I would use a dedicated satellite which only has the required passive services executed in its zone. This would also be good if some security breach happens as it limits the data someone can get on the system. ---
**Author:** ![ronanlucio](https://community.icinga.com/letter_avatar_proxy/v4/letter/r/b4bc9f/32.png) [@ronanlucio](https://community.icinga.com/u/ronanlucio)\ **Post date:** [November 6, 2020, 2:33pm UTC](https://community.icinga.com/t/api-public-accessible/5981/3 "2020-11-06T14:33:09Z")
Hi Dirk, Thank you for your reply, it seems we’re on the same page. It’s a specific product that will be installed in hundreds-to-thousands of sites distributed over different locations and countries, so it sounds to be really public. I also have the same thoughts about using a dedicated satellite with specific permission and preferable for using certificate-based authentication. At this moment I only need a hostalive check, which makes it a little bit easier and will be implemented using heartbeats to icinga’s process-check-result api. Besides that, our servers use to be hardened, secured, and patch managed. So my main concern is because icinga API allowed several kinds of actions that I intend to restrict via user’s permissions settings (allow only process-check-result). Is it possible to restrict it only for GET (read-only) queries? thank you, ---
**Author:** ![dgoetz](https://community.icinga.com/user_avatar/community.icinga.com/dgoetz/32/917_2.png) [@dgoetz](https://community.icinga.com/u/dgoetz)\ **Post date:** [November 6, 2020, 3:04pm UTC](https://community.icinga.com/t/api-public-accessible/5981/4 "2020-11-06T15:04:54Z")
No, limiting to GET is not possible, also the queries require POST for more complex filters and all actions need them, too. If you could live with the limitations so a transparent reverse proxy which limits to GET would be perhaps an option, but not for the passive checks. Are the sites owned by different customers or something similar to group them to limit the risk of a certificate and key getting lost and the work needed to change it if required? Perhaps it would be also good idea to use openssl commands directly to limit lifetime instaed of using Icinga 2’s defaults. ---
**Author:** ![nexo1960](https://community.icinga.com/letter_avatar_proxy/v4/letter/n/c57346/32.png) [@nexo1960](https://community.icinga.com/u/nexo1960)\ **Post date:** [November 6, 2020, 3:41pm UTC](https://community.icinga.com/t/api-public-accessible/5981/5 "2020-11-06T15:41:17Z")
You could configure the reverse proxy to only proxy /v1/actions/process-check-result everything else will result in a “404 file not found”. In that way you can grant granulated access to some api functions. ---
**Author:** ![ronanlucio](https://community.icinga.com/letter_avatar_proxy/v4/letter/r/b4bc9f/32.png) [@ronanlucio](https://community.icinga.com/u/ronanlucio)\ **Post date:** [November 7, 2020, 10:49pm UTC](https://community.icinga.com/t/api-public-accessible/5981/6 "2020-11-07T22:49:16Z")
> Are the sites owned by different customers or something similar to group them to limit the risk of a certificate and key getting lost and the work needed to change it if required? it’s for some group of customers, so I can it managing certificates per customer/group is an option ---
**Author:** ![ronanlucio](https://community.icinga.com/letter_avatar_proxy/v4/letter/r/b4bc9f/32.png) [@ronanlucio](https://community.icinga.com/u/ronanlucio)\ **Post date:** [November 7, 2020, 10:50pm UTC](https://community.icinga.com/t/api-public-accessible/5981/7 "2020-11-07T22:50:16Z")
> You could configure the reverse proxy to only proxy > /v1/actions/process-check-result everything else will result in a “404 file not found”. sounds good as well