Feature idea: API keys

[cb372]

Suggested by @seratch

Let backend services more closely track/control who calls their APIs.

The idea:

• Use Octoparts admin UI to generate one or more API keys for a given part
• Give these API keys to clients, who send them with their requests
• Octoparts records API keys in logs
• Optionally (configured per-part), Octoparts rejects any requests that don't have a valid API key

[mauhiz]

isn't that what the serviceId is for? Also, is there a point in rejecting clients?

[lloydmeta]

Assuming "API keys" means id-and-shared-secret and using them for authentication (how is TBD), this seems like a reasonable idea.

Advantages that I can think of are:

1. More secure; allows Octoparts to be exposed to the outside world.
2. Forces Octoparts clients to send real identification so logs and metrics are more accurate

Wondering if access from insecure clients (JS, Android apps that can't keep secrets) is also going to be considered in this discussion.

[mauhiz]

More secure

Security was never a concern (as this application was designed to run on a trusted network). If it becomes a requirement, then there are other areas we should be looking into. I think this is a good idea to implement security, although we should think about it a little bit more. Currently exceedingly open areas are :

• /swagger-ui
• anyone can modify anything on Admin UI
• constrained resources (pool sizes, amount of parts one can own) are currently completely unbounded
• target backend is a free field (making Octoparts a kind of open proxy)

Forces Octoparts clients to send real identification

It is as real as they want... as they can re-generate their key once in a while. In this sense, it is equivalent to making serviceId required.

[lloydmeta]

Security was never a concern

Indeed. Maybe it should though. At the moment, once someone gains access to the trusted network (not farfetched), Octoparts makes it trivial to take down an entire set of systems because there is zero security. I think we can do a bit better.

If it becomes a requirement, then there are other areas we should be looking into.

Definitely; although this is feature might not be a bad place to start. For others, we should probably discuss them in other issues.

It is as real as they want... as they can re-generate their key once in a while. In this sense, it is equivalent to making serviceId required.

I think there may be a disconnect between what we have in mind because having API id-secret style authen/autho is totally different from simply making serviceId required. A rough idea that I had in mind (could always just use OAuth1/2):

Client(name: String, credentials: Seq[Credentials])

Credentials(id: String, secret: String)

HttpPartConfig(... authorisedClients: Seq[Client]...)

The general idea is that authentication is done when a request comes into Octoparts using id and shared secret (Credential), so we end up with a Client. Then for each PartRequest, we check if the Client is authorised to hit that endpoint using the authorisedClients of the corresponding HttpPartConfig.

[mauhiz]

I see, OP's original idea is to have the client send API key per part...

[seratch]

Thank you for your response.

Let backend services more closely track/control who calls their APIs.

Although we don't always need such a feature, we sometimes need to figure out clients especially for sensitive APIs. Furthermore, this feature may improve not only security but troubleshooting on production environment.

If we could do the following things on admin UI, that will be great.

• enable API key validation (maybe Authorization header) for parts|services
• create/delete credentials for parts|services (credentials should not be exposed to other team)

If we could set multiple targets (parts or services) flexibly, that'll be better. Creating new model such as AuthoriazationRule which can hold partIds or serviceIds? Just an idea.

I'd like to contribute this feature when I have time.

[mauhiz]

To summarize this discussion :

• this feature is a Good Idea™.
• implementation should not be too hard; however it should be made clear in the docs how it works, since some users are not using the client libs we supply
• demand for this feature seems to be low
• @seratch volunteered ;)

[seratch]

Thanks. In our use cases, this feature looks like a YAGNI thing right now. Realistically, we already have lots of Octoparts aggregation API calls without API keys. Just to distinguish Octoparts clients, sending their own cilent identifiers (hostname, env/config variable) as a request header (e.g. X-Octoparts-Cient-Id) will be useful enough. If such a feature is already demanded, I will work on this.