Access Control Lists (ACLs)

This section describes functionality in the Java/Scala SDK related to ACLs (Access Control Lists), for information about how the ACLs are defined and control access see Using ACLs

Default ACL in project templates

If no ACLs is defined at all in a Kalix service Kalix will allow requests from both other services and the internet to all components of a Kalix service.

The Kalix quickstarts and Maven archetypes the sbt g8-template all include a less permissive ACL for the entire service, to not accidentally make services available to the public internet, just like the one described in the next section.

Defining an ACL for the entire Kalix Service

A default ACL for the entire Kalix Service can be defined by placing a kalix_policy.proto file among the protobuf descriptors of the service. It should only contain a kalix.file(acl) annotation:

Java
src/main/proto/com/example/kalix_policy.proto
syntax = "proto3";

package com.example;

import "kalix/annotations.proto"; (1)

option (kalix.file).acl = {
  allow: { service: "*" } (2)
};
1 Import the needed Kalix annotations from kalix/annotations.proto
2 Allow access from all other services, but not the public internet
Scala
src/main/proto/com/example/kalix_policy.proto
syntax = "proto3";

package com.example;

import "kalix/annotations.proto"; (1)

option (kalix.file).acl = {
  allow: { service: "*" } (2)
};
1 Import the needed Kalix annotations from kalix/annotations.proto
2 Allow access from all other services, but not the public internet

This is the default ACL included in the quickstarts and project templates, it allows calls from any other Kalix service deployed in the same project, but denies access from the internet.

Inspecting the principal inside a service

Checking the ACLs are in general done for you by Kalix, however in some cases programmatic access to the principal of a call can be useful.

Accessing the principal of a call inside of a service is possible through the request metadata Metadata.principals(). The Metadata for a call is available through the context (actionContext, commandContext) of the component.

ACLs when running unit tests

In the generated unit test testkits, the ACLs are ignored.

ACLs when running integration tests

When running integration tests, ACLs are enabled by default but can be explicitly disabled per test by running the test with Settings.withAclDisabled.

For integration tests that call other services that have ACLs limiting access to specific service names Settings.withServiceName allows specifying what the service identifies itself as to other services.

KalixTestKit.getGrpcClientForPrincipal makes it possible to get a integration test client that is authenticated with specific credentials for calling a service with ACLs.