APPUiO Control API Architecture

This page describes the APPUiO Control API. It adheres to the decision taken in APPUiO Control API and it follows the features asked in Functional Requirements Targeting the Portal.

General Principles

Kubernetes API

The Control API is built upon the Kubernetes API and adheres to it’s design principles.

API object field: .status

The status field (also called "Status subresource") represents the current observed state and external information. It is read-only to the end-user.

API object field: .spec

The spec field contains the desired state for reconciliation.

Virtual vs. CRD based resources

Some resources are not persisted to etcd and are only available virtually, others are persisted to etcd and are defined and represented via CustomResourceDefinition (CRDs).

Virtual resources are accessible via an API Server Extension. These resources are similar to views in a relational database. The benefit of providing these resources instead of only using CRDs is that we can calculate access permissions dynamically for every request. The same concept is also used by OpenShift with its Project resource which represents RBAC filtered Namespaces (see kube-projects). And we can also find it in Kiosk for example.

Authentication and Authorization

Authentication against the API server is done by the APPUiO IdP. It’s always the same subject (user) which is being used throughout the whole APPUiO Cloud ecosystem.

For authorization, standard Kubernetes RBAC is being used. Kyverno policies can be used to implement enhanced policies, for example the number of resources of a specified kind a user is allowed to create.

There are several layers of authorization:

  • Kubernetes RBAC

  • Kyverno policies

  • Virtual resources with filtering

Resource Scopes

Resources on the Kubernetes API server can either be cluster scoped or namespace scoped.

Each APPUiO Control API instance is represented by one Kubernetes API server instance. This allows us to leverage the scoping concept of the Kubernetes API server to reflect the scopes in the APPUiO Cloud domain. Also, by doing it that way, standard Kubernetes RBAC rules can be used for permission handling on an organization level.

APPUiO Cloud Global resources are available on the Kubernetes global scope (no namespace) whereas organization level resources are namespace scoped.

Global

Kubernetes cluster global resource.

Organization

Kubernetes namespaced resource.

Resources

Name Scope Type

Organization

Global

Virtual (represents filtered Namespace resources)

OrganizationMembers

Organization

CRD

User

Global

CRD

Team

Organization

CRD

Zone

Global

CRD