Multi-customer configuration requirements enquiry

[David P]

Hi,

Looking at implementing KrakenD, I was wondering if you could address these questions for me:

1. How would KrakenD control or assess usage of an API/application per customer? Some examples would be:
   1. Throttling
   2. Metering
   3. Authentication
      
      
2. Leading on from question 1, how would KrakenD control/assess for all customers? Examples would be:
   1. Versioning
   2. Logging
   3. Auditing
   4. Unifying separate APIs into a single layer

I couldn't seem to find anything in the documentation on how KrakenD would control the usage of different customers individually and how they would all customers?

Hopefully that makes sense.

Thanks.

[Albert Garcia]

Hi David!

Thanks for reaching out through our community email list. I've just answered your previous email directly to your inbox, including it below:

----
Dear David,

Thank you for your interest in KrakenD. I'm happy to provide some insights into your queries.

Regarding API/Application Usage Control Per Customer

• Throttling: KrakenD offers a per-client rate limiting feature, which allows you to control the number of requests a client can make to your API within a certain timeframe. This helps prevent any single client from overloading your system. You can learn more about this feature in our rate-limiting documentation.
• Metering: KrakenD integrates with a wide range of telemetry systems that can track and measure API usage. This allows you to monitor how your API is being used and make data-driven decisions. You can see the full list of available metrics and tracing exporters in our telemetry documentation.
• Authentication: KrakenD Enterprise Edition supports both API Key authentication and JWT-based authentication. This allows you to control access to your API on a per-client basis, ensuring that each client can only access the resources they are authorized to use. We support many Identity Providers, like Auth0, Keycloak, and Okta. You can learn more about this in our API Key authentication and JWT authentication documentation.

Control/Assessment for All Customers

• Versioning: While KrakenD is agnostic to your versioning strategy, its ability to decouple your external API contract from your internal services implementations makes it a great tool for implementing a robust versioning strategy. You can learn more about this in our API Gateway Deployment Guide.
• Logging: KrakenD integrates with a variety of logging systems, allowing you to capture detailed logs of API usage. This can be invaluable for debugging, performance monitoring, and auditing purposes. You can find more details in our logging documentation.
• Auditing: KrakenD's extensive logging capabilities can be used in conjunction with external auditing tools to track and audit API usage. For instance, we offer an integration with ELK, which provides powerful search and visualization capabilities on top of your log data. You can learn more about this in our ELK integration documentation.
• Unifying Separate APIs into a Single Layer: This is one of the core features of KrakenD. It acts as an API Gateway, aggregating responses from multiple backend services into a single, unified API layer for the client. This allows you to provide a consistent, easy-to-use API to your clients, regardless of the complexity of your backend services.

I hope this information helps clarify the capabilities of KrakenD. However, I understand that these topics can be complex and might raise further questions. To ensure you have all the information you need, I would like to invite you to a one-on-one call where we can dive deeper into your specific needs and how KrakenD can meet them.

Please feel free to schedule a call with me at your earliest convenience using my availability calendar. I'm looking forward to our conversation and exploring how we can help you achieve your goals with KrakenD.

Best regards,

	Albert García Business Director

Confidentiality Notice: This email, including any attachments, may contain confidential and privileged information for the sole use of the intended recipient(s). Any unauthorized review, use, disclosure, or distribution is prohibited. If you are not the intended recipient, please contact the sender immediately and destroy all copies of this email. Thank you. This email has been sent in accordance with the European Union General Data Protection Regulation (EU GDPR).

--
You received this message because you are subscribed to the Google Groups "KrakenD Community" group.
To unsubscribe from this group and stop receiving emails from it, send an email to community+...@krakend.io.
To view this discussion on the web visit https://groups.google.com/a/krakend.io/d/msgid/community/2edb9dd6-d1be-4ace-8a9d-41294dcedacan%40krakend.io.

[David P]

Hi,

Can you add multiple customers/users with the extra_config or endpoint_extra_config feature?

E.g.

"version": 3,

"timeout": "30s",
"extra_config": {

   "/customerA": { 
         "max_rate": 15,
         "client_max_rate": 2
       },
   "/customerB": { 
         "max_rate": 20,
         "client_max_rate": 3
       },


Then further down you'd call the endpoints as such:

"endpoints": [
      { "endpoint": "/customerA/user1",
        "backend": [
            {
               "url_pattern": "/customerA/user1",
               "host": ["customerA-backend-service.example.com"],
             }
       ]
},

{
      "endpoint": "/customerB/user1",
       "backend": [
            { ... }
        ]
},

Something like that would work?

Thanks.

On Thursday, 27 July 2023 at 14:54:34 UTC+1 Albert Garcia wrote:

Hi David!

Thanks for reaching out through our community email list. I've just answered your previous email directly to your inbox, including it below:

----
Dear David,

Thank you for your interest in KrakenD. I'm happy to provide some insights into your queries.

Regarding API/Application Usage Control Per Customer

• Throttling: KrakenD offers a per-client rate limiting feature, which allows you to control the number of requests a client can make to your API within a certain timeframe. This helps prevent any single client from overloading your system. You can learn more about this feature in our rate-limiting documentation.
• Metering: KrakenD integrates with a wide range of telemetry systems that can track and measure API usage. This allows you to monitor how your API is being used and make data-driven decisions. You can see the full list of available metrics and tracing exporters in our telemetry documentation.
• Authentication: KrakenD Enterprise Edition supports both API Key authentication and JWT-based authentication. This allows you to control access to your API on a per-client basis, ensuring that each client can only access the resources they are authorized to use. We support many Identity Providers, like Auth0, Keycloak, and Okta. You can learn more about this in our API Key authentication and JWT authentication documentation.

Control/Assessment for All Customers

• Versioning: While KrakenD is agnostic to your versioning strategy, its ability to decouple your external API contract from your internal services implementations makes it a great tool for implementing a robust versioning strategy. You can learn more about this in our API Gateway Deployment Guide.
• Logging: KrakenD integrates with a variety of logging systems, allowing you to capture detailed logs of API usage. This can be invaluable for debugging, performance monitoring, and auditing purposes. You can find more details in our logging documentation.
• Auditing: KrakenD's extensive logging capabilities can be used in conjunction with external auditing tools to track and audit API usage. For instance, we offer an integration with ELK, which provides powerful search and visualization capabilities on top of your log data. You can learn more about this in our ELK integration documentation.
• Unifying Separate APIs into a Single Layer: This is one of the core features of KrakenD. It acts as an API Gateway, aggregating responses from multiple backend services into a single, unified API layer for the client. This allows you to provide a consistent, easy-to-use API to your clients, regardless of the complexity of your backend services.

I hope this information helps clarify the capabilities of KrakenD. However, I understand that these topics can be complex and might raise further questions. To ensure you have all the information you need, I would like to invite you to a one-on-one call where we can dive deeper into your specific needs and how KrakenD can meet them.

Please feel free to schedule a call with me at your earliest convenience using my availability calendar. I'm looking forward to our conversation and exploring how we can help you achieve your goals with KrakenD.

Best regards,

Albert GarcíaBusiness Director     

Confidentiality Notice: This email, including any attachments, may contain confidential and privileged information for the sole use of the intended recipient(s). Any unauthorized review, use, disclosure, or distribution is prohibited. If you are not the intended recipient, please contact the sender immediately and destroy all copies of this email. Thank you. This email has been sent in accordance with the European Union General Data Protection Regulation (EU GDPR).

[Albert Garcia]

Hi David,

No, you can define different client identification strategies using the strategy parameter (https://www.krakend.io/docs/endpoints/rate-limit/#strategy), but it's not currently possible to have different rate limits for different users. 

Best regards,

	Albert García Business Director

Confidentiality Notice: This email, including any attachments, may contain confidential and privileged information for the sole use of the intended recipient(s). Any unauthorized review, use, disclosure, or distribution is prohibited. If you are not the intended recipient, please contact the sender immediately and destroy all copies of this email. Thank you. This email has been sent in accordance with the European Union General Data Protection Regulation (EU GDPR).

[David P]

Hi Albert,

If we choose the "ip" strategy, how can we distinguish and uniquely identify individual customers? Won't this apply the rate limit to every incoming request since they all have an IP address?

Is it possible to set a rate limit for a specific customer based on a unique header, while allowing other customers with no headers to use the endpoint unrestrictedly?

Thank you for taking the time to reply to my questions, really appreciate it!

[Albert Garcia]

Hi David,

Note that the "strategy" would help KrakenD differentiate users based on given criteria, so if you define "ip" as the "client identification strategy", KrakenD will assign your defined rate limit (let's imagine 5 requests per second) to each client separately, based on their IP address. 

You can also use a strategy based on a unique header. For instance, if you assign a "X-User-ID" header with the user ID, each user would have a separate rate limit based on each different ID.

I hope this helps clarify how the "strategy" parameter works.

Best regards,

	Albert García Business Director

Confidentiality Notice: This email, including any attachments, may contain confidential and privileged information for the sole use of the intended recipient(s). Any unauthorized review, use, disclosure, or distribution is prohibited. If you are not the intended recipient, please contact the sender immediately and destroy all copies of this email. Thank you. This email has been sent in accordance with the European Union General Data Protection Regulation (EU GDPR).

[David P]

Hi Albert,

Brilliant, that answers my question.

Additionally, there are inquiries concerning the storage of API keys in plaintext within the configuration file. Is there an alternative method to store API key authentication securely, avoiding plaintext storage?

As I progress through the initial list of questions, I may come across additional inquiries while reviewing the relevant documentation you provided.

Kind regards,
David

[Albert Lombarte]

Hi David,

You don't need to "store" the API keys in the KrakenD configuration file. It is enough that KrakenD can retrieve its values during startup time. There are several ways to accomplish this using KrakenD tools or external ones. For instance, using a flexible configuration, you could inject values from environment variables. You could also pre-process secret management systems, e.g.:

$ aws secretsmanager get-secret-value --secret-id myAPIKeys --query 'MySecretString' --output text | base64 -d > settings/apie-keys.json

But in any case, API keys are an Enterprise functionality and are not included in the community version. If you are interested in enterprise functionality, please get in touch.

El dia dilluns, 31 de juliol de 2023 a les 13:17:08 UTC+2, David P va escriure:

[David P]

Hi Albert,

Thank you for your reply it was really helpful. I was curious about rather than the actual implementation of the API Key authentication.

I have an additional question about the flexibility of KrakenD's configuration. Can I utilize separate configuration files for individual users or customers? For instance, having "customerA.json" and "customerB.json" configuration files, and using environment variables to determine which config file to load?

Does this approach enables a multi-customer configuration setup without the need to duplicate endpoint listings for different users based on "strategy."?

It provides a more organized and manageable way to cater to distinct customer requirements while avoiding redundancy in the configuration.

Kind regards,
David

[Albert Lombarte]

Hi David,

Yes, this is possible. You could use different setting files per customer. The flexible configuration allows you to work all kind of magics. For this specific question, the syntax might not be obvious at first, but it would be something like:

{{index . (env "CHOSEN_CUSTOMER") . }}

In the example above, you would set an ENV var like CHOSEN_CUSTOMER=customerA and the variable contains all settings under customerA.json

The flexible configuration avoids repeating code and create a more compact and manageable settings structure.

Let me know if you have any further questions

Missatge de David P <davidp...@hotmail.co.uk> del dia dt., 1 d’ag. 2023 a les 10:42:

[David P]

Hi Albert,

Thank you for taking the time to answer, it's incredibly helpful!

Regarding the configuration, in "customerA.json," would you list the endpoints and extra_config just as you would in the KrakenD.json structure (Scope/Endpoint/Backend) or would it only contain environment variables for that specific customer?

However, instead of hardcoding values in the KrakenD.tmpl file, you would reference the environment variables related to Customer A for those fields.

For example (krakend.tmpl):

{ "port": {{ .CustomerA.service.port }},
"extra_config": {{ marshal .CustomerA.service.extra_config }} }

Is that correct?

Kind regards,
David

[David P]

Also another question if I may:

What are the network layer and ingress prerequisites for KrakenD's operation? Are there specific requirements that KrakenD necessitates in this regard, or is KrakenD compatible with a wide range of network layers and ingress systems?

Thanks again.
David

[Albert Lombarte]

Hi David,

There are many ways of working with KrakenD flexible configuration. If you are going to have a different gateway per customer I would create a unique settings folder for each of them and instead of "carrying" the customer identifier and customer name across the configuration you work with the same data all of the time. e.g: FC_SETTINGS=settings/customerA, FC_SETTINGS=settings/customerB, etc

As per the network, there are no requisites for KrakenD to operate and is agnostic of its surrounding pieces and hops.

Albert Lombarte CEO

Missatge de David P <davidp...@hotmail.co.uk> del dia dc., 2 d’ag. 2023 a les 14:51:

[David P]

Hi Albert,

Thank you so much for answering my questions.

Another query for the rate limiting:

Is "strategy" a one fit to all?

Is there a mechanism to establish distinct rate limits for each customer? I'm uncertain how to approach this unless there's a provision within the flexible configuration to dynamically adjust customer-specific requirements.

While a straightforward approach like the one below does not work, is there an alternative approach to achieving per-endpoint customization?

I understand the code snippet below won't work, just an idea of what I'd like to achieve. Is there a way to achieve something like this below?

"qos/ratelimit/router": { "client_max_rate": 100, "every": "1h", "strategy": "header", "key": "x-standard" }, { "client_max_rate": 2000, "every": "1h", "strategy": "header", "key": "x-premium" }


Kind regards,
David

[David P]

To add to this question:

If flexible configuration is plausible, I'm curious if it's feasible to dynamically adjust these configurations per customer, including modifying rate limits and other functionalities.

Essentially, is it possible to maintain customer-specific configurations in separate files and seamlessly reference them in the main configuration as needed? Without having to add multiple entries of the same endpoint with slightly different configuration settings applied depending on the customer.

Thanks again, I do appreciate it!

[Albert Lombarte]

Hi David,

About the ratelimit configuration, the open source version strategy is a one fit all solution. You would need to code your own plugin to do what you are trying to achieve.

About the flexible configuration, it depends on what you understand by "customer". If the customer is a settings file, and you have a gateway per customer, yes you can do that. If a customer is an end-user then not.

	Albert Lombarte CEO

Missatge de David P <davidp...@hotmail.co.uk> del dia dv., 4 d’ag. 2023 a les 17:35:

[David P]

Hi Albert,

Thanks again for the response.

As per the rate limit comment:  While the open-source version provides a one fit for all solution, does the Enterprise edition offer distinct features that could potentially address this issue and eliminate the necessity for developing a custom plugin?

Regarding the flexible configuration comment:  In this scenario, there is a single gateway serving multiple end users making requests through it. Is there a method to achieve this? How would you recommend addressing this situation?

Kind regards,
David

[Albert Lombarte]

Hi David

Under Enterprise, we offer better rate-limiting approaches. Feel free to reach us at sa...@krakend.io with a corporate email to discuss them.

If you have customers that require completely different endpoint settings, you will need to create all the variations in the config (maybe with a different endpoint), or under Enterprise using Dynamic Routing, but I would need to understand well what is what you want to do per customer to see if its feasible.

By the way, your email bounced every single time I replied. 

	Albert Lombarte CEO

Missatge de David P <davidp...@hotmail.co.uk> del dia dc., 9 d’ag. 2023 a les 13:56:

[David P]

Hello Albert,

I might be inclined to explore the Enterprise plan if that's the case.

Regarding Dynamic Routing, let's consider a scenario where we have a shared endpoint, such as "/user/{id}", but distinct requirements for different customers. For instance, we aim to allow customer 1 to access this endpoint up to 5 times per minute, while customer 2 should have a limit of 2 times per minute.

In the context of Dynamic Routing, the question arises: how can we differentiate between these cases and route them accordingly?

I'm seeking to comprehend a situation in which two end users interact with the same endpoint but are directed differently based on their headers or other factors.

If you happen to have a code example illustrating this, I'd greatly appreciate it.

Thank you!

P.S. as for the email bounce I'll look into that, apologies.

[Albert Lombarte]

Hi David,

If you have different limits per customer, and you have hundreds or thousands of customers where each of them has individual limits, I see this cumbersome to manage with KrakenD. Think that KrakenD apply the same rate limits to all users of an endpoint (EE is working on extending this as we speak), so in a scenario where you have only 2 customers, you should declare one endpoint for each. E.g.:

{

"$schema": "https://www.krakend.io/schema/v2.4/krakend.json",

"endpoints": [

{

"endpoint": "/user/1",

"extra_config": {

"qos/ratelimit/router": {

"client_max_rate": 5,

"every": "1m"

}

}

},

{

"endpoint": "/user/2",

"extra_config": {

"qos/ratelimit/router": {

"client_max_rate": 2,

"every": "1m"

}

}

},

]

}

If you have 10000 users, then this is complicated to say the least.

If on the other side, you have "groups of limits", let's name them gold and silver plans, and users fit in one or the other, you could use dynamic routing to send them to the right endpoint. For example:

{

"$schema": "https://www.krakend.io/schema/v2.4/krakend.json",

"endpoints": [

{

"endpoint": "/user/{id}",

"backend": [

{

"url_pattern": "/plan/{input_headers.X-Plan}/user/{id}" <-- dynamic routing to a specific plan

}

]

},

{

"endpoint": "/plan/silver/user/{id}",

"extra_config": {

"qos/ratelimit/router": {

"client_max_rate": 5,

"every": "1m"

}

}

},

{

"endpoint": "/plan/gold/user/{id}",

"extra_config": {

"qos/ratelimit/router": {

"client_max_rate": 5,

"every": "1m"

}

}

}

]

}

The user would pass in the plan (or you would pass it using internal information) a header or something similar doing the match.

This is an idea.

But if you would like to discuss EE, please get in touch at sa...@krakend.io and have a proper conversation.

Best regards,

Albert Lombarte CEO

Missatge de David P <davidp...@hotmail.co.uk> del dia dt., 15 d’ag. 2023 a les 10:23:

[David P]

Hi,

Thank you again Albert, very informative.

What prevents a user from simply appending to the API call command, such as using "curl -H 'X-Plan: gold' (api)" to bypass rate limits and gain higher access etc?

Is there a method to uniquely identify users based on their plan without allowing such appendages? One possibility is using a JWT claim field, not sure if that is something KrakenD could see. Could this approach be effective?

Is there a feature within the community edition that enables this type of authorization information or dynamic routing the only option for this which is enterprise edition?

Kind regards

[Albert Lombarte]

Hi David,

I don't think you can do any of this in community without coding the solution yourself.

As per the Enterprise, you can do all types of validations with the security policies, including checking if the provided plan in the header matches the plan in a claim of the JWT for instance. If the user is tampering the header, permission denied.

El dia dilluns, 21 d’agost de 2023 a les 16:17:44 UTC+2, David P va escriure: