I am working in data platform on Kubernetes. Therefore, I will need to install
several databases like Ceph (or Minio), Postgresql, Elasticsearch
A kafka cluster
a SQL engine like Trino (former PrestoSQL)
several api servers
Multiple users and applications (internal to Kubernetes or not) will need to be authenticated and authorized to use theses components above.
For authorization I have found a project like Open Policy Agent which fits my wish to have a centralized and unified way to control it.
I would like the same thing for authentication but I am still looking for it.
There are different ways to authenticate, the most interesting ones being:
TLS certificate
OAuth2
Kerberos
But all the above components does not implement these methods.
For instance, I was interested to use Keycloak. It is perfectly suited for API servers, Kafka but not for Postgresql.
Do you know some solutions, alternatives to my problem?
Like Jonas good mentioned in the comment:
This totally depends on what your systems support. It is easiest if they support JWT-tokens for authentication, then the microservices can use its serviceAccount.
One of the solutions might be to use service-mesh, like istio and JWT (JSON Web Tokens). Here is also istio documentation about JWT. In simple terms, microservice will generate a JWT and istio will check if the token is correct. This guide shows exactly, how Istio Authorization Policy works.
Here you can find a very good article that explains how such authorization works step by step. It presents various methods of implementation. It shows their strengths and weaknesses.
It's also worth taking a look here. The official istio security documentation explains how to approach the subject of authorization. You can find there all supported authorization methods.
You can also create your custom action to delegate the authorization to external system. Here is the guide, how you can do it.
Kubernetes also supports 3rd party authentication tools: Keycloak, Auth0 or Google Auth. Here are guides, how to secure Kubernetes clusters with:
Keycloak and istio
Auth0 and Istio
Google Auth and Istio
Related
I'm writing a service to be deployed on Kubernetes. Clients will be other services, not people, and those services may be in other namespaces or even clusters. My goals are:
Authenticate the calling services
Authorize the calling services
Apply some policies based on the identity of the calling service (like quota)
I understand that Kubernetes doesn't provide services that really help with any of these, and I'll need to build something explicit into my service. I'd like to understand what the current best practice is and how to maximize what's available in Kubernetes or in the ecosystem to make these goals achievable while minimizing the coding and administrative burden. A few options that I've considered:
Custom username / shared-secret. I could just pass out shared secrets to all of the calling services, and write my own custom code to verify that the shared secret matches. I assume passing these around as Bearer tokens would be the right move. Would using Kubernetes serviceaccount and role objects be reasonable containers for these shared secrets? If so, are there libraries that make the lookups, associations, and policy work easier?
JWT. JWT seems more intended for passing around claims, like end-user identity, and would seem to require that all of the participating components share the same JWT secret. Since I don't want calling-service-foo to be able to authenticate as calling-service-bar, it's not clear that JWT is the right move. Thoughts?
mTLS. I could issue TLS certificates for all of the participating services. Are there components I can use to automate the issuance of these certificates? Should I try to use Kubernetes serviceaccount or role objects to manage these, or maybe roll my own CRDs?
Istio. It seems like Istio can do a lot of this transparently, but so far all of the resources I've found that explain this seem to assume transparency is a goal. Since I will need the identities of the calling services, though, is it possible to get that out of Istio? Can this work if my callers aren't in my cluster?
SPIRE (spiffe.io). This looks like it matches well for my use cases, but it seems new and I don't know how much experience people have with it.
Do any of these options (and please correct my understanding of any of them) stand out as best practices, or are there others I should be considering?
Thank you!
What you need is a component that acts as the gateway to the microservices API endpoints. That kind of component belongs to a category of software called "API management" (Wikipedia page) and its usage is not limited to Kubernetes only.
There are many choices of API management software such as listed in the Wikipedia page but my project uses Gravitee and so far we are loving it due to its simple administration UI. Feel free to explore it at https://gravitee.io/.
N.B. I'm not related in any way to Gravitee.io apart from being one of the users (although I did contribute to one PR)
I know I'm late now but if anyone else is looking:
Istio has included Multicluster support and it makes the communication painless.
reference: https://istio.io/latest/docs/setup/install/multicluster
We have a Mulesoft Cloudhub environment which we are planning to deploy public APIs and we also have a VPC configured where we will deploy private APIs.
I'm looking at how best to secure the APIs and seen the following approaches:
Basic Authentication
Client Id and secret
OAuth
LDAP
SAML
My query is when should you use each one? Are their example use cases? E.g. OAuth seems to be more secure than basic authentication and client id and secret so why not use OAuth all the time and forget about the other two?
Thanks
OAuth is geared more towards authorisation rather than just authentication.
For example OAuth 2 has many different flows geared towards different use-cases. Such as 3 legged OAuth allowing you to use an external identity provider allow users to be authorised to access your resources. In a way, you’re not performing any authentication at all.
Http basic can still have a purpose in simple scenarios MAYBE when the cost and/or effort of using something else is not worth it and it’s internal network and the OJ already have some sort of ldap or active directory type thing is use for other apps (and using SSL is very important here as basic auth credentials are plain text)
For client id and secret, although it is similar to username/password, it’s more in the semantics - you are trusting a client rather than a person with the credentials.
For example, you can use client id to authenticate actual clients like a mobile application or a web app. Client id implementation like MuleSoft’s API Manager also allow you to add policies such as rate limiting and SLA based rate limiting so you can limit specific client applications to not overload your API.
You could use it alongside OAuth. Client ID/Secret for accessing the API but OAuth for authorising the end-user .
Here is a more detailed article discussing the pros and cons of the various common api auth mechanisms and a link to choosing between the various OAuth flows for your use-case.
https://nordicapis.com/3-common-methods-api-authentication-explained/
https://auth0.com/docs/api-auth/which-oauth-flow-to-use
What is the best way to secure a connection between an Elasticsearch cluster hosted on Elastic Cloud and a backend given that we have hundreds of thousands of users and that I want to handle the authorization logic on the backend itself not on Elasticsearch?
Is it better to create a "system" user in the native realm with all the read and write accesses (it looks like the user feature is intended for real end-users) or to use other types of authentication (but SAML, PKI or Kerberos are also end-user oriented)? Or using other security means like IP based?
I'm used to Elasticsearch service on AWS where authorization is based on IAM roles so I'm a bit lost here.
edit: 18 months later, there's no definitive answer on this, if I had to do it again, I would probably end up using JWT.
I'm working on a RESTful API, that works as backend for a mobile application.
The underlying system is based on Jersey and Jetty server, but my question is more generic (for any JaX-RS compliant system).
I'm looking for a standard solution to secure it. I read about many answers talking about JWT, tokens, ... and OAuth.
But all solutions except OAuth do not have a Standard and neither any implementation apart from some basic examples on github.
I'm concern as OAuth seems a good solution for third party access on your API but I think is a great overhead for straight access & tokenization, from a Mobile app or a Website AJAX. Is hard for me to accept that is the only available solution.
Here I'm asking, am I wrong about OAuth (beeing designed for third party access)? or other access solutions are not available (eg opensourced) as they are only custom made for the specific purpose?
My scenario requirements:
Token should be self certified (eg JWT) so a proxy/load balancer can filter out a not signed one, before reaching the endpoint.
No need for a token/renew system as we have a distributed cache holding a SESSION and therefore a missing session mean that authorization expired/was revoked.
The second one, may not be true as if we issue a certificate to an App for 1 year, and revoke it after 1 hour. This token may be still used by an attacker to "frustrate" our cache for 1 year.
Excuse my ignorance but can PicketLink be implemented as an IDP within weblogic?
I am looking to create a light weight IDP Proxy to be able to accept SAML requests and issue SAML Assertions based on simple authentication handled elsewhere so not looking for anything that provides too much.
I wondered if picketlink offered a simple API to do this and whether it would work on a welbogic domain.
Weblogic has its own, built-in SAML implementation that is tightly integrated with the rest of their platform. It is fully configurable from their admin console. Use that instead of PicketLink.
http://docs.oracle.com/cd/E28280_01/web.1111/e13707/saml.htm#SECMG252