Apache Apisix: Open-Source API Gateway and API Management Platform • Hacker News Board

Re: Apache Apisix: Open-Source API Gateway and API Management Platform

#61

Post by chao-zhang » Sat, Sep 17, 2022, 4:50 AM UTC

adamckay wrote: post #60

chao-zhang wrote: post #40

Earlier quoted context omitted.

Apache APISIX also has several security features to help reinforce API security. For instance: 1. It can dynamically manage lots of TLS certificates and do the TLS/SSL terminate or use mTLS to communicate with the upstream; 2. Plugins like ACL, IP Restriction, CSRF, and Referrer Restriction restrict API access in different dimensions.

Is it possible to perform mTLS from client->APISIX gateway and pass on the verified certificate details to the upstream (e.g. via headers)? Or is mTLS only possible with client->pass through APISIX->upstream? It's not quite clear from the docs.

It's feasible while you have to write a bit of code to assemble the certificate details to the API request (e.g., request headers, or query string).

mTLS is both possible for client -> APISIX and APISIX -> upstream.

Re: Apache Apisix: Open-Source API Gateway and API Management Platform

#62

Post by bzp2010 » Sat, Sep 17, 2022, 6:13 AM UTC

adamckay wrote: post #60

chao-zhang wrote: post #40

Earlier quoted context omitted.

Apache APISIX also has several security features to help reinforce API security. For instance: 1. It can dynamically manage lots of TLS certificates and do the TLS/SSL terminate or use mTLS to communicate with the upstream; 2. Plugins like ACL, IP Restriction, CSRF, and Referrer Restriction restrict API access in different dimensions.

Is it possible to perform mTLS from client->APISIX gateway and pass on the verified certificate details to the upstream (e.g. via headers)? Or is mTLS only possible with client->pass through APISIX->upstream? It's not quite clear from the docs.

As a complement to the first reply, I created a simple DEMO that will implement your needs and I placed it on the GitHub gist [1].

[1] https://gist.github.com/bzp2010/6ce0bf7c15c191029ed547245471...

Re: Apache Apisix: Open-Source API Gateway and API Management Platform

#63

Post by jjzhiyuan » Mon, Sep 19, 2022, 3:01 AM UTC

Some insights: Apache APISIX Slack channel[1] is under the Apache Software Foundation, and 1000+ members joined in to ask questions or share cases around Apache APISIX API Gateway or its Ingress Controller.

After asking users why they prefer Apache APISIX than other solutions, there have four important points:

1. Feature Rich: Many users need to use API Gateway with OpenID Providers (e.g., Auth0, Keycloak), other solutions sold this feature on Enterprise Product only. There has one How-to guide "Use Keycloak with API Gateway to protect your APIs".

2. Quick Support: Apache APISIX has many active contributors and maintainers, they keep watching activities on GitHub[3], Slack[1], Mailing List and other channels. When users ask questions, they respond quickly, the goal is to help users onboard quick.

3. Apache Project: After APISIX project was donated to the Apache Software Foundation, it means nobody can change its License any more, so enjoy Apache projects ([https://www.apache.org](https://www.apache.org)).

4. Benchmark is excellent, and the most active maintainer's explaination here[4]: LuaJIT + Nginx.

P.S Welcome to join Apache APISIX Slack[1] to discuss, and you can find many useful posts from its blog[5].

- 1. https://apisix.apache.org/slack - 2. https://apisix.apache.org/blog/2022/07/06/use-keycloak-with-... - 3. https://github.com/apache/apisix - 4. https://apisix.apache.org/blog/2021/08/25/why-apache-apisix-... - 5. https://apisix.apache.org/blog

Re: Apache Apisix: Open-Source API Gateway and API Management Platform

#64

Post by CoolCold » Sun, Sep 25, 2022, 10:11 AM UTC

threeseed wrote: post #28

matt-p wrote: post #20

What is the main benefit to running a gateway? Auth should already be handled by the api and adding things like rate limiting, ip address filtering ,caching and so on are ridiculously trivial..

> rate limiting, ip address filtering ,caching and so on are ridiculously trivial Maybe if you're running one instance of your API server. But if you're not then API Gateways end up being significantly simpler.

> Maybe if you're running one instance of your API server.

I'm not sure how it differs, can you explain more? From my perspective each API instance is just one more `server x.x.x.x:port` in my `upstream someapi { ... }` section in Nginx config. Be it 1 or 20.

No difference from regular Loadbalancing as I see it.

For multiple APIs (api1, api2...) you end up with different `location {}` and using specific `upstream {..}` blocks upon request from deb/backend team.