APPUiO Control API: Organization
| This resource implements the "Manage Organizations" features. |
List operations on Kubernetes resources can not be filtered by RBAC, it’s a binary operation:
Resources can either be listed or not, there is no way to give access only to a sub-set.
To circumvent this limitation, Organization is a virtual resource.
The Organization resource represents a filtered and formatted list of standard Kubernetes Namespace resources which have specific labels and annotations.
It is assumed that the Organization resource is used for all operations, the represented Namespace must not be directly manipulated.
Object
apiVersion: organization.appuio.io/v1
kind: Organization
metadata:
name: acme-corp (1)
spec:
displayName: Acme Corp. (2)
Field mapping from the represented Namespace resource:
| 1 | metadata.name |
| 2 | metadata.annotations[organization.appuio.io/display-name] |
apiVersion: v1
kind: Namespace
metadata:
name: acme-corp
labels:
appuio.io/resource.type: organization (1)
annotations:
organization.appuio.io/display-name: Acme Corp. (2)
| 1 | Identify resource type, used by the API server to filter for namespaces representing organizations |
| 2 | Reflected in the Organization object as spec.displayName |
| Name | Type | Resource | Description |
|---|---|---|---|
|
label |
|
Identifies the resource type in the scope of the APPUiO Control API |
|
annotation |
|
Display name of the organization |
Access Control
We use standard Kubernetes role-based access control for Organizations with two distinct differences.
-
Access needs to be granted for
organizationsresources in API grouprbac.appuio.ioand not for resources in API grouporganization.appuio.io. Permissions can be configured through bothRolesandRoleBindings, as well asClusterRolesandClusterRoleBindings. Similarly toNamespaces, permissions configured by aRolein namespacefooonly affectsOrganizationfoo. -
For
listandwatchverbs the API server will only return resources that the user also has permission toget
|
The |
Generated RBAC
By default there are two ClusterRoles that configure access for organization members
appuio-organization-viewer-
View (read only) access to an organization
apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: appuio-organization-viewer rules: - apiGroups: ["rbac.appuio.io"] resources: ["organizations"] verbs: ["get"] ... # Get and list permission for other resources appuio-organization-admin-
Admin (read / write) access to an organization
apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: appuio-organization-admin rules: - apiGroups: ["rbac.appuio.io"] resources: ["organizations"] verbs: ["get", "patch", "edit"] - apiGroups: ["rbac.authorization.k8s.io"] resources: ["rolebindings"] verbs: ["get", "list", "watch", "patch", "edit", "delete"] ... # Edit permission for other resources
Creating, listing, and watching organizations can be done by all authenticated users.
When creating an Organization, a RoleBinding in the created Namespace is generated.
This RoleBinding assigns the appuio-organization-admin ClusterRole to the creating user.
This allows the creator to manage the new Organization and assign permissions to new members.
Organization Membership
All members of an organization are configured in an OrganizationMembers resource.
apiVersion: appuio.io/v1
kind: OrganizationMembers
metadata:
name: members
namespace: org-acme-corp
spec:
userRefs: (1)
- name: kate.demo
- name: peter.muster
status:
resolvedUserRefs: (2)
- name: kate.demo
- name: peter.muster