Munkiserver REST API

[joraff]

It would be beneficial to many persons and teams interested in integration if munkiserver had a REST API.

[joraff]

Things I'd likely use in an api

list of units (:units#index)
list of computer_groups in :unit (:unit_shortname/:computer_group#index)
CRUD on :unit/:computer (maybe just CRU)

At first thought, that should be all I need for integration. Others, please post what you think you may use!

[dayglojesus]

I second this proposal. Management of computer records is paramount. Also, exposing an API for these types of operations would greatly increase Munki Server's ability to integrate with other management systems.

[rickychilcott]

Do people have a preference of JSON or XML? Both?

I think @joraff is on track with his listing, though I'd like to see CRUD on :unit/:computers.

As for authentication, do we want to have an API key for each user (and allow users to be API only) which will allow us to leverage the already existing permissions system?

[joraff]

I think most languages can read JSON nowadays, though serving XML & JSON is trivial.

My only additional request would be to not use a routed subdomain for the api. Although that would otherwise be my preferred starting point, our DNS options here are limited. I image others at larger institutions are in a similar situation.

[FromStoneage]

Generally nowadays API responds in JSON, but its very easy to add support
to both XML and JSON. (might require explicitly add extension for which
format when requesting)

I think it's a good idea to secure API. There are couple ways we can do
that, add API Key is one, Oauth is another. Also this might be depend on
the application you want to integrating with, if they support Oauth or
other methods.

Jonathan Hu

On Tue, Oct 23, 2012 at 1:23 PM, Ricky Chilcott [email protected]:

Do people have a preference of JSON or XML? Both?

I think @joraff https://github.com/joraff is on track with his listing,
though I'd like to see CRUD on :unit/:computers.

As for authentication, do we want to have an API key for each user (and
allow users to be API only) which will allow us to leverage the already
existing permissions system?

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/158#issuecomment-9716696.

[rickychilcott]

We can do OAuth or API Keys. I just figured API keys would be easier to implement without major changes to our user-based codebase. Would it be ok to piggy back off of Users to allow this? Key-based APIs are slightly less protective, but are much easier to work with, in my opinion.

Should we require an HTTPS connection for all API calls? I also agree with @joraff conclusion that the API should not be based on DNS. We could namespace the api to something like:

https://munkiserver/api/:unit/:computer.json

But for ease of maintainability, we can keep our routes all the same and not even namespace it. That would personally be my preference.

[dayglojesus]

I think the notion of piggy backing off the internal user db is the way to go, but if one were to do this, requiring HTTPS is absolutely critical, as Ricky mentioned.

I also think adding hostname/IP restrictions as an extra measure of security is an excellent idea -- I would not feel comfortable with any host on our network being able to access the API.

Is that possible?

[joraff]

@dayglojesus As long as an admin isn't running munkiserver with a proxy, it should be trivial through CanCan. The API will probably be pretty simple as well using Devise's :token_authenticatable.

[joraff]

Er, scratch that -- not using Devise.

[rickychilcott]

Based on my understanding of how DeployStudio works, the agent that is running the scripts is the computer which is being reimaged. So, limiting by hostname or IP address would be too limiting.

Sent from my iPhone

On Oct 24, 2012, at 4:17 PM, Brian Warsing [email protected] wrote:

I think the notion of piggy backing off the internal user db is the way to go, but if one were to do this, requiring HTTPS is absolutely critical, as Ricky mentioned.

I also think adding hostname/IP restrictions as an extra measure of security is an excellent idea -- I would not feel comfortable with any host on our network being able to access the API.

Is that possible?

—
Reply to this email directly or view it on GitHub.

[dayglojesus]

I would hope that the hostname/IP ACL would be optional.

[rickychilcott]

@dayglojesus Do you envision this to be site-wide or hostname/IP ACL per user?

[bruienne]

I've been doing some rudimentary tinkering with adding web services to enable non-authenticated automatic enrolling of new managed clients as well as batch uploading/importing of an existing Munki repo. I'm still digging into general best practice as far as implementing web services with Rails goes, but I'm curious to know if anything has been done by anyone in this realm. I'd like to get involved as it would be a big boost to Munkiserver functionality both for automation and interoperability purposes.

[bruienne]

FWIW, I've been using JSON so far as it is easy to integrate with Python's requests/urllib modules. I've made both a client token (additional GET parameter) and exceptions in the before_filter setup work; I'm sure CanCan has much better/easier ways to do this as well.

[rickychilcott]

I have some experience with building APIs, what might be helpful is a big list of resources that would be nice to have accessible (both read/write capability). The hardest part is usually the permission settings related to the API done correctly. From there, API specific controllers could be mapped out and built.

There is already a very comprehensive permission system for users (or principals), and I think we should reuse that because it's already there.

[jnraine]

I agree @rickychilcott.

I think a big win for the API would be adding HTTP basic auth to munkiserver. Once done, adding JSON responses to various actions is quite trivial! That list of most-wanted actions would be helpful.