ACL's , Organizations, Users and API

[carlos....@nbrsolutions.pt]

Hello,

I'm a newbie when it comes to Kong. And I have several questions:

1. Does Kong only supports API key by user? 
   
2. How can I define Organization support by leveraging the Consumer Object?
   
3. How can I segregate my API so that a specific organization group ACL can only Add, Update, Delete API's and another ACL can only read?
   
4. Can I have one API defined and associate which consumers will have access or the concept is the other way around and is a mapping of 1 API - 1 Consumer?
   

Thanks

[Martin Danielsson]

Hello back,

I'll give this a go.

1. Kong does not have the concept of "user", it only has "consumers", which can be either: A user or an application or whatever. It's what you define it to do. That's the level you you work on. Kong doesn't care at all whether a consumer is semantically a person or a role. It needs a consumer. Period.

2. This question you would have to rephrase, as it's not clear what you are trying to achieve. See above: If you don't need granular access levels or specific roles, and just need an "organization", then define a consumer which corresponds to this organization. If I got this completely wrong, please clarify what you are trying to do.

3. Two possibilities I can think of right now (there are probably a lot more):

  a) Split your API into a "reading" API and a "writing" API, which would need to have  separate resource level end points (/yourapi/read and /yourapi/write). This is not very clean, but it would definitely prevent your consumers to actually hit the backend service at all

  b) Use two ACL groups for your API. One "read" and one "readwrite" group (or similar, you are free to chose). Then assign your consumers to the appropriate ACL group; Kong will forward the groups a consumer belongs to in a X-Consumer-Groups custom header you then could leverage to decide whether an operation is allowed or not. This would have to be done in your backend though. It still gives you the benefit that you don't have to hard wire any consumer in the backend service, but just decide based on groups which rights a consumer has. This in fact is a rudimentary RBAC concept using ACLs.

4. You are free to associate any consumer with any API by the means of ACLs. Read up on how that works, I think that will help you.

Best regards,

Martin

[carlos....@nbrsolutions.pt]

Hello Martin,

Thanks for the answer,

If i a use case can help,

What I'm trying to achieve is:

1. Multi-tenant Environment 
2. A tenant will be represented by and organization
3. Organization will have multiple users
4. Segregated environment,in terms of security and application logic, so that I can collect information for different levels: May it be which users called that API and/or organization it belonged to

So with is scenario do you think it's possible to use Kong to address it?

[Martin Danielsson]

Hi Carlos,

I - personally! - would not try to drive it that far. My simplistic solution to that would be to get each organization a separate Kong instance. That's as segregated as it gets.

Depending on your load, Kong does not need much in terms of hardware, it runs (on top of Postgres) happily on a 40$ VM from wherever. (AWS, Azure,...). Automate your deployments instead of investing in very elaborate security group concepts. My personal opinion on that is that this gives you a lot more flexibility.

This was supposedly not the answer you were looking for :-D

Best regards,

Martin