Dear Kuksa Community,
This is Emirhan. I am the project lead for Eclipse ioFog.
We want to contribute an optional authorization mode to Kuksa Databroker. It is for Databroker running as a microservice on an ioFog edge node. I am sharing our motivation and the planned design. Feedback and comments are welcome.
Short background on ioFogEclipse ioFog is a lightweight, hardware and workload agnostic platform for securely deploying, orchestrating, and operating containerized workloads across distributed edge environments from a single control plane.
What the platform includes:- Edgelet: A far/device edge node agent and embdded container runtime with an OTA binary footprint of under 35 MB. It targets device-edge nodes on amd64, arm64, armv7, and riscv64, and supports both traditional Linux containers and WASM containerized workloads.
- Cloud Native Edge Cluster Controller: Runs on Kubernetes or bare-metal/VM backends and translates cloud-native deployment practices into edge-native execution and fleet operations.
- Distributed Messaging Fabric: A NATS-based, mTLS-protected messaging layer with built-in decentralized JWT authentication and authorization for edge microservices, multi-tenancy, and isolated namespaces per edge application. NATS accounts, users, and access policies are created declaratively as part of a workload's desired state. When a workload is deployed, the Controller automatically generates its NATS account for distributed application and user identities for workloads, and creds files, securely mounts the appropriate creds file into the workload. This provides application-level messaging isolation and secure communication with effectively zero manual NATS configuration for the distributed edge applications.
- Service Interconnection Network: A Layer 7 overlay tcp-briding network with mTLS by default, enabling edge microservices to communicate securely across isolated devices without manual network setup.
When an Edgelet is provisioned, it gets an Ed25519 key pair. Edgelet uses that key to authenticate to the Controller. It also uses that key to sign service account JWTs for the microservices it runs.
Roles look like Kubernetes RBAC. A Role declares apiGroups, resources, and verbs. Users assign a Role to a microservice. Edgelet embeds those rules in the service account token. Today this is used for the Edgelet local API. The same Role model can carry rules for other APIs.
What we want to contribute:
Databroker would get a second auth mode:
"KUKSA_AUTH_MODE=iofog"
The existing oauth mode stays as it is. JWT scope and --jwt-public-key do not change. Non-ioFog deployments are not affected.
In iofog mode, Databroker would:
1. Read its own Edgelet service account token. The default path is /var/run/secrets/
edgelet.iofog.org/serviceaccount/token2. Cache the node Ed25519 public key from that token (edgelet.iofog.org.node.publicKey).
3. Verify inbound JWTs from other microservices signed by the same Edgelet key.
4. Authorize each request from kuksa.val/v2 RBAC rules in the client token. Databroker’s own Role is not used for inbound access.
Why this mode:- Edge-native auth. No extra OAuth IdP on the device. We reuse Controller Role to Edgelet service account token.
- Least privilege. Each microservice gets its own kuksa.val/v2 rules in its JWT.
- No manual key distribution. Databroker learns the public key from its own projected token.
- Backward compatible. Default remains oauth, and no breaking change for non-iofog deployments
Example role:
---
apiVersion:
iofog.org/v3 kind: Role
metadata:
name: kuksa-speed-reader
rules:
- apiGroups:
-
edgelet.iofog.org/v1 resources:
- microservices/config/self
- auth/whoami
- system/gps
- microservices/control/self
verbs:
- get
- apiGroups: [kuksa.val/v2]
resources: [Vehicle.*.*]
verbs: [get]
- apiGroups: [kuksa.val/v2]
resources: [Vehicle.Speed]
verbs: [get, update]
A microservice would reference that Role on its service account:
---
apiVersion:
iofog.org/v3 kind: Microservice
metadata:
name: app-uses-kuksa-broker
spec:
....
serviceAccount:
roleRef:
kind: Role
name: kuksa-speed-reader
---
RBAC verb to Kuksa Val v2 / VISS:-get: GetValue, GetValues, Subscribe (per path)
- list: ListMetadata
- create: CreateEntry / register signal
- update / patch: Actuate if the entry is an actuator. PublishValue if it is a sensor.
- * : All of the above for matching resources
This is in our backlog. If this direction looks wrong, or if you want different verb or glob semantics, please say so. We would adjust the design.
Cheers,
