stack-dependency.md

Stack Dependency

Stacks may depend on access to other custom resources in the API. These dependencies are provided in the dependsOn field of the Stack spec.

Each dependency results in an RBAC Rule authorizing the service account used by the Stack controller to access the resources defined in the Stack.

The following Stack body would result in the Stack's controller running under a service account with roles permitted access to foo.

apiVersion: stacks.crossplane.io/v1alpha1
kind: Stack
spec:
  dependsOn:
  - crd: foo.stack.crossplane.io/v1alpha1
...

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
rules:
- apiGroups: ["foo.stack.crossplane.io"]
  resources: ["foo"]
  verbs: ["*"]
...

Permission Scopes

Crossplane is installed with two deployments with differing access levels.

The Crossplane workload types (KubernetesApplication) are managed with crossplane service account granted full access to all core Crossplane resource types. This service account also has access to manage events and secrets from the Kubernetes core API group (referred to as "" in ClusterRoles).

The Crossplane Stack Manager (SM) manages Stack types (Stack, StackInstall, StackDefinition, others) using a crossplane-stack-manager service account. This service account is bound to the cluster-admin ClusterRole which has full capabilities to create and manage any resource. This empowers stacks and template stacks to authorize stack controllers to deploy and manage any resource.

Restrictions

Every stack controller should not be granted the full unrestricted access to the Kubernetes API that the SM requires.

The SM restricts the access each Stack controller inherits to the resource types that Stack claims to own and depend on. It is important that users understand the capabilities being afforded to each Stack. UIs should strive to present this information in a meaningful way.

While many users may appreciate the flexibility that permits Stacks to manage any resource type, the Crossplane authors are acutely aware of the need to restrict these capabilities within a given environment.

To do so, the SM may restrict the APIGroups available in Stack permissions fields. This field should not be confused with the dependsOn and customresourcedefinitions (owned) fields which are derived from the app.yaml file, informing the permissions value during automated Stack resource creation.

At present, the SM offers a command line option that prevents any stack from receiving access to resources from the core Kubernetes API group.

--restrict-core-apigroups

This argument enables a policy that will block access to the following classes of Kubernetes API groups:

• Any dot-less API Group. This covers a range of API groups that should not match the naming pattern of resources Stack authors intend to manage. This includes (but is not limited to):
  • "" preventing access to secrets, events, pods, and others
  • apps and batch preventing access to deployments and jobs
  • apiextensions preventing access to custom resource definitions
  • policy preventing access to POD budgets and security policies
• *.k8s.io suffix match preventing access to several API groups with mixed responsibilities including RBAC, Ingress, CSI, and many more

Stacks depending on these types will fail to reconcile when --restrict-core-apigroups is supplied to the SM.

It is also worth noting that all Stack controllers receive rules to access a base set of resources deemed necessary for Stack controller operation. This includes access to configmaps, events and secrets.

Future updates may extend the resource controls available through the SM.