1

At deployment time, I register my microservices in the following way:

  • They register themselves in Keycloak to have an identity as a confidential client;
  • Then they call an endpoint on a dedicated internal microservice "AUTH-SRV" that grants them the appropriate permissions/roles;
  • They also register themselves with the permissions that they are granted in this "AUTH-SRV" as a client for the other internal microservice that they need to talk to.

All my microservices are deployed on premises (without Docker support).

It's working but I find it's not very secure to let a service register itself and its permissions to call others services.

On the other hand, I do not know how to find a better way to do it. For example, if an admin user needs to register a service by hand in a back-office UI, it's not manageable, because we have more than 30 microservices. It will require a lot of work and my application could easily break at runtime because of a missing permission granted between two internal services.

If I opt for another solution, like authorizing all internal calls between services, I may not have a secure in-depth solution.

The question is, is there a more secure way to register and manage internal service to service permissions?

Improve this question
8
  • I'm afraid it's not clear what the specific security issues are that you're trying to solve here. Why is it not secure to allow an application to register itself and its own permissions at deployment time? Commented Jan 22, 2023 at 17:59
  • What I find insecure is above all the fact that each service records the rights they are authorized to use to call other services. Commented Jan 22, 2023 at 20:09
  • Can you give an example of the kind of permissions that your services are registering? Commented Jan 23, 2023 at 9:36
  • @Dypso I understood that part from the post, but in a scenario where all of the applications, tools and systems involved are fully trusted and locked down from any untrusted parties, there'd be no security issue with this, so I'm I'm unclear as to exactly which part of the scenario is untrusted and trying to understand the root source of the security issue you're trying to fix. For example, are the applications built from untrusted sources or 3rd-parties? Or are there untrusted parties with access to the infrastructure and/or deployment tooling? Commented Jan 23, 2023 at 10:10
  • 1
    I think there's a trade-off and balance between autonomy for teams maintaining each particular service vs dependencies on trusted engineers. I can think of an example at a large organisation who allowed teams to publish their own account-wide AWS IAM permissions (AWS account shared across teams); each team had their own "IAM" Git repository containing AWS JSON policy documents for Terraform. The main branches being essentially read-only for everyone aside from a small group of trusted engineers who would need to manually review/approve any PR in git to merge changes to those policies. Commented Jan 23, 2023 at 10:49

1 Answer 1

Reset to default
2

There are several ways to improve the security of registering and managing internal service-to-service permissions. I will summarize the most popular ones.

One approach is to use an external identity provider (IDP) to authenticate and authorize the services, rather than allowing the services to register themselves with Keycloak as you are currently doing. This way, an administrator can control the IDP and revoke accesses as needed.

Another approach is to use a centralized service discovery and registration system, such as Netflix Eureka or Consul, to manage the registration and discovery of services. This way, services can register themselves with the service discovery system, but the system can be configured to only allow certain services to access certain other services based on their roles or permissions.

You could also use a service mesh to manage service-to-service communication. Service meshes like Istio or Linkerd, provide a secure way to control service-to-service communication, by allowing you to define rules for service-to-service communication, and enforce those rules at runtime.

Personally, I prefer the service mesh solution, as it offers improved observability and traffic management capabilities in a microservices architecture. Having said that, the other solutions are also valid and each has its advantages and disadvantages so it is best to decide based on your specific context.

Improve this answer

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.