public class Scope
extends Object
Hierarchical scopes for role bindings. This is used to scope roles bindings or other scoped
metadata to individual clusters or other levels of scope. It is also used to limit the data
cached in embedded authorizers.
Concrete scopes consist of a hierarchical scope path and one or more clusters that may be used
to uniquely identify any resource within the scope.
For example, with a two level scope consisting of root scope "myorg" and clusters
"kafka-cluster:clusterA" and "kafka-cluster:clusterB", roles may be assigned at
cluster level for "clusterA" and "clusterB". Authorization service providing metadata for
all clusters will use the root scope "myorg" to process role bindings of both clusters,
while a broker belonging to "kafka-cluster:clusterA" only uses role bindings of clusterA.
Cluster ids may not be globally unique. For example, Connect cluster id may be unique only within
the context of its kafka cluster. Hence the combination of cluster ids is used to define a unique
scope, e.g. {"kafka-cluster" : "kafkaClusterA", "connect-cluster" : "connectCluster1"}.
JSON Examples:
1) A Scope with no hierarchy.
{
"path": [],
"clusters": {
"kafka-cluster": "kafkaClusterA",
"connect-cluster": "connectCluster1"
}
}
2) A Scope with hierarchy.
{
"path": ["org=myorg", "env=staging"],
"clusters": {
"kafka-cluster": "kafkaClusterA",
"connect-cluster": "connectCluster1"
}
}
3) A Scope with only hierarchy.
{
"path": ["org=myorg"],
"clusters" : {}
}