Let's say I'm developing some service that needs to send requests to some 3rd party endpoint. This 3rd party endpoint is secured in some way (Basic, OAuth2, or mTLS) and in my source code I don't want to bother with the security part. What would you suggest to solve that problem? Right now for the mTLS part I developed a proxy that enriches all my request with the client certificate, but still, maybe there is already a solution present in the envoy or istio?
Related
We're developing a web application (SPA) consisting of the following parts:
NextJS container
Django backend for user management
Data API (FastAPI) protected with API keys, for which we also provide 3rd party access
The NextJS container uses an API key to access the data API. We don't want to expose the API key to the client (browser), so the browser sends the API requests to the NextJS container, which then relays it to the data API, see here. This seems secure, but is more complicated and slower than sending requests from the browser to the data API directly.
I'm wondering if it's possible to whitelist the web application in the data API, so that the client (browser) can call the data API directly without API key, but 3rd parties can't. FastAPI provides a TrustedHostMiddleware, but it's insecure because it's possible to spoof the host header. It has been suggested to whitelist IPs instead, but we don't have a dedicated IP for our web application. I looked into using the referer header, but it's not available in the FastAPI request object for some reason (I suspect some config problem in our hosting). Also, the referer header could be spoofed as well.
Is there even a safe way to whitelist our web application for data API access, or do we need to relay the request via NextJS container and use an API key?
Is there even a safe way to whitelist our web application for data API
access,
No, you need in all case an Authentication mechanism, something before the backend that check if the client is an authorize client.
The simplest pattern is using the NextJS container as the proxy. Proxy that have an api-key to call the backend ( what you are currently doing ).
There is many way to implement a secured proxy for a backend, but this authentication logic should not be inside the backend but in a separate service ( like envoy , nginx ... )
I'm reading through https://kubernetes.io/docs/reference/access-authn-authz/authentication/, but it is not giving any concrete commands and it is mostly focusing when we want to create everything from scratch. It's also explaining auth for engineers using Kubernetes.
I have an existing deployment and service (with exposed external IP) and would like to create the simplest possible authentication (preferably token based) for an external user accessing the exposed IP. I can't add authentication to the services since I don't have access to their code. If somebody could help me with some commands I would be grateful.
The documentation which referred is for authentication with k8s (for api accesses). This is not for application layer authentication.
However I can suggest one way to implement application layer authentication without changing the service at all. You can redirect the traffic to nginx (or any other reverse proxy) which can perform the authentication and redirect the authenticated user to service directly. It can also perform some kind of authorization too.
There are various resources available which can help you choose various authentication mechanism available in nginx such as password file based mechanism (link) or JWT based authentication (link)
What are good arguments in favor to use or not to use Keycloak behind Api gateway (Kong)?
There is a tradeoff to putting it behind the proxy: you will not be able to easily protect all of your services by applying the OIDC plugin on the global level. Instead, you will need to individually configure every service with its own OIDC plugin. This is because you will need at least one service that is not protected by the OIDC plugin so that user-agents can authenticate through that service. Unless you're planning to implement some other form of security on that service or need some other services that Kong can easily implement as requests pass through it, I don't see the point of putting Keycloak behind the proxy. That's not to say there aren't good reasons to do it, I'm just not aware of them.
I've set Keycloak up outside of the proxy, and have had good results. Here's what it looks like:
I'm writing a blog post about this set up now which I will release next week. I will try to remember to update my answer here when it is complete.
Edit
Links to blog:
Part 1,
Part 2
It is not good practice, in fact I would suggest to put it outside, in the DMZ. In this way that IDP can be leveraged by all APIs that you want to publish and authenticate using the API gateway. This is an example of applying such authentication flow with Keycloak: https://www.slideshare.net/YuichiNakamura10/implementing-security-requirements-for-banking-api-system-using-open-source-software-oss
Your concern might be then: how do I protect such a critical resource like an IDP authenticating all my services?
Reasonable concern which you can address by:
ensuring autoscaling of the IDP based on authentication request
configuring all the needed threat mitigation options on Keycloak (https://www.keycloak.org/docs/latest/server_admin/#password-guess-brute-force-attacks)
add a WAF in front of the IDP with feature such as DDOS prevention and Intelligent Threat Mitigation based on traffic patterns
IP or Domain whitelisting, if you know where all your customers are connecting from
restrict port exposure for the IDP
Kong is an API gateway that'll be in the "hot path" - in the request and response cycle of every API request. Kong is good at efficiently proxying lots of requests at very low latency.
Keycloak and other IAM offerings can integrate with Kong - but they aren't placed in the hot path. Keycloak is good at managing users and permissions and providing this information to systems like Kong, when requested.
Perhaps these links will be helpful https://github.com/ncarlier/kong-integration-samples and https://ncarlier.gitbooks.io/oss-api-management/content/howto-kong_with_keycloak.html
Is not a good practice, a good Enterprise API Gateway has the obligation to meet (or give you the access to customize) all the advanced authentication and authorization standards available in KEYCLOAK.
But in some circumstances, If you already have a API Gateway with a lot API´s configured (with transformation rules, route rules) and this Gateway can´t provide advanced features for authentication and authorization (ex. 2 factor authentication or Oauth2 authorization code/openId / SAML) and you need more security ASAP, go ahead while looking for a gateway that best meets your needs
I have configured the cas server to communicate with a cas client application by cas protocol and the service ticket is in form of jwt token. I want to make the cas server be able to forward this ticket to a server outside, for example the server which running my own ticket handler instead of the server running the cas client. Is there any possibility to achieve this in a good manner?
Is there any possibility to achieve this in a good manner?
Absolutely not, and this is not a good idea at all. You either need to use proxy tickets, or a proper application of something like OIDC and a relevant profile. Anything else likely is a spaghetti and will lead to a broken implementation.
I'm building a RESTful API which is only accessible by TLS. Where should SSL connection be implemented?
by RESTful API itself, my API is written in golang, which handles SSL easily.
by a SSL reverse proxy, here I'm using nginx.
I would prefer 2nd approach because nginx handles caching and static deliveries better.
Should I implement my API HTTP-only now? In my opinion the system is secure, as long as nginx the reverse proxy is serving SSL only and my API exposes itself to nginx only.
I'm not sure if there is a 3rd approach, while I keep my API SSL only and nginx passes through all requests transparently.
TL;DR: I will choose between the 2nd or 3rd option, depending on the scenario. If you want to publish the API on Internet, never opt for the first one.
The most secure option is the third one: implement your API to allow SSL connections only, and publish to Internet using a reverse proxy anyway.
The pros are the communication with your API will be secure even for internal connections. That will give you protection from internal attackers. The cons are the extra processing load on your server to manage the SSL security and that can impact on the performance.
Anyway, you should look for cost-benefit. That's the reason why it will depend on the scenario. For example, if your API will not be accessed by internal users, but only for internal services, and the load on the server is heavy, you can consider the 2nd approach: plain HTTP por internal communications and SSL termination for Internet.