ACLs are used to control fine-grained access policies of users to resources; and are validated, stored, and evaluated as an AccessPolicy resource in Omni.
At the moment, only Kubernetes cluster access (group impersonation) is supported.
Structure
AccessPolicy
The AccessPolicy is a single resource containing a set of user groups, a set of cluster groups, a list of matching rules and a list of tests.
metadata:namespace:defaulttype:AccessPolicies.omni.sidero.devid:access-policyspec:usergroups:# match level-1 users by fnmatch expressionlevel-1:users: - match:level-1*# match level-2 users by label selectorslevel-2:users: - labelselectors: - level=2# match level-3 users by explicit listlevel-3:users: - name:admin1@example.com - name:admin2@example.comclustergroups:dev:clusters: - match:dev-*staging:clusters: - match:staging-* - match:preprod-*production:clusters: - match:prod-*rules: - users: - group/level-1clusters: - group/devrole:Operator - users: - group/level-1clusters: - group/stagingrole:Readerkubernetes:impersonate:groups: - read-only - users: - group/level-2clusters: - group/dev - group/stagingrole:Operator - users: - group/level-2clusters: - group/productionrole:Readerkubernetes:impersonate:groups: - read-only - users: - group/level-3clusters: - group/dev - group/staging - group/productionrole:Admin# simple rule - without links to user or cluster groups - users: - vault-admin@example.comclusters: - vaultrole:Admintests:# level-1 tests - name:level-1 engineer has Operator access to dev clusteruser:name:level-1-a@example.comcluster:name:dev-cluster-1expected:role:Operator - name:level-1 engineer has read-only access to staging clusteruser:name:level-1-b@example.comcluster:name:staging-cluster-1expected:role:Readerkubernetes:impersonate:groups: - read-only - name:level-1 engineer has no access to production clusteruser:name:level-1-c@example.comcluster:name:production-cluster-1expected:role:Nonekubernetes:impersonate:groups: []# level-2 tests - name:level-2 engineer has Operator access to staging clusteruser:name:something@example.comlabels:level:"2"cluster:name:preprod-cluster-1expected:role:Operator - name:level-2 engineer has read-only access to prod clusteruser:name:something@example.comlabels:level:"2"cluster:name:prod-cluster-1expected:role:Readerkubernetes:impersonate:groups: - read-only# level-3 tests - name:level-3 engineer has admin access to prod clusteruser:name:admin1@example.comcluster:name:prod-cluster-1expected:role:Admin# vault-admin tests - name:vault-admin has admin access to vaultuser:name:vault-admin@example.comcluster:name:vaultexpected:role:Admin
List of strings representing Kubernetes impersonation groups.
Role
A Role is the role to grant to the user.
Possible values: None, Reader, Operator, Admin.
Test
A Test is a single test case.
Test cases are run when the resource is created or updated, and if any of them fail, the operation is rejected.
name:support engineer has full access to staging clusteruser:name:support1@example.comcluster:name:staging-cluster-1expected:role:Operatorkubernetes:impersonate:groups: - system:masters