API Access

I just want to confirm, a user that has the BuildMaster API key has full access to everything in BuildMaster, correct?

If this is the case, is there any methodology for limiting access to API functions on a per user or per group basis?

Product: BuildMaster
Version: 4.8.6

If you're using the Native API, then you would need to wrap the calls and check for privileges that way.

However, part of our v5 plan is to build out simpler endpoints for specific tasks (like Otter's Job Orchestration API), so if there are tasks you're looking for, we can definitely add those.

Can you elaborate on how one would need to wrap the calls and check for privileges?

Leaving the permissions checks up to the individual developer that's handed the API key seems risky. Eventually an individual is going to reach a point where they skip the permissions checks because it's faster and simpler to code a solution. Then they have full access to anything on the BuildMaster server.

The Otter Job Orchestration API appears to be a better solution, but I still don't believe it's ideal because it doesn't appear there's anything to trace when a "bad" user has compromised the secret.

Am i understanding this correctly?

This is definitely something we intend to address as part of our v5 roadmap; there just hasn't been a huge customer demand for automating BuildMaster using the sort of "temporary API access key" approach that has grown popular in the more consumer-facing things like Twitter, GitHub, etc.

We may add this if there' demand and similar adoption in other tools in the space, but in our experience, it's generally more complicated for administers to manage and set-up. So they just set up one "access key" and give it to everyone.

It's particular challenging for us to solve in the same manner because of the way BuildMaster scopes privileges (by application and environment), and because the Native API can work cross-application/environment.

So, if it's a requirement to give limited access to Developers, the current best approach is to wrap the native api with a permissions wrapper, and then check if that user is authorized based on the AD group they're in, etc., based on the action they want to perform.