SPK RBAC¶

Overview¶

The Service Proxy for Kubernetes (SPK) Controller uses the default ServiceAccount to access the cluster API by default. To limit the resources and namespaces that the SPK Controller can manage, the appropriate Kubernetes ServiceAccount and Role-based Access Control (RBAC) objects must be installed. Also, to specifiy which users can perform SPK Helm installations, additional RBAC objects must be installed.

This document guides you through installing Kubernetes RBAC objects to limit SPK Controller’s cluster API and namespace access.

API access¶

To grant minimal API access within a specified namespace to both the SPK Controller and the user accounts that manage the SPK Controller, the follwoing objects must be confiured and installed in the cluster:

Object	Description
`ServiceAccount`	A Pod-level account that binds the SPK Controller to ClusterRole and Role objects.
`ClusterRole`	Grants minimal access to cluster-level resources, specifically the SPK Custom Resource Definitions (CRDs).
`ClusterRoleBinding`	Binds the ServiceAccount and user accounts to the ClusterRole.
`Role`	Grants minilam access to resources within the specified namespace.
`RoleBinding`	Binds the ServiceAccount and user accounts to the Role.

Requirements¶

Ensure you have:

A working Robin cluster.
Installed the SPK Software.

Procedures¶

Note: The full list of SPK Controller RBAC objects can be downloaded here.

SPK Controller¶

Use these steps to configure and install the objects that allow minimal API access for the SPK Controller.

Copy the ServiceAccount object into a YAML file, and adapt the metadata.name and metadata.namespace values for your environment:
```
apiVersion: v1
kind: ServiceAccount
metadata:
  name: spk-service-account
  namespace: spk-utilities
```

Install the ServiceAccount object:

kubectl apply -f spk-service-account.yaml

Verify the ServiceAccount has been created in the cluster:

In this example, the ServiceAccount named spk-service-account has been created.

kubectl get sa -n spk-utilities

NAME                   SECRETS 
default                1      
spk-service-account    1     

Copy the ClusterRole object for the service account into a YAML file, and adapt the metadata.name parameter for your environment:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: spk-sa-cluster-role
  # "namespace" omitted since ClusterRoles are not namespaced
rules:
- apiGroups:
  - "" # "" indicates the core API group
  resources:
  - namespaces
  - endpoints
  - pods/status
  - services
  - secrets
  verbs:
  - get
  - update
  - patch
  - list
  - watch
- apiGroups:
  - apiextensions.k8s.io
  resources:
  - customresourcedefinitions
  verbs:
  - get
  - list
  - watch
- apiGroups:
  - apps
  - extensions
  resources:
  - ingresses
  verbs:
  - create
  - get
  - list
- apiGroups:
  - discovery.k8s.io
  resources:
  - endpointslices
  verbs:
  - list
  - watch
- apiGroups:
  - k8s.f5net.com
  - dos.k8s.f5net.com
  - dns.k8s.f5net.com
  resources:
  - '*'
  verbs:
  - watch
  - get
  - list

Install the ClusterRole object:

kubectl apply -f spk-sa-cluster-role.yaml

Verify the ClusterRole has been created in the cluster:
```
kubectl get clusterrole | grep spk-sa-cluster-role
```
In this example, the ClusterRole named spk-sa-cluster-role has been created.
```
spk-sa-cluster-role
```

Copy the ClusterRoleBinding object into a YAML file, and adapt the metadata.name, metadata.namespace, subjects.name, and subjects.namespace values for your environment:

kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: spk-sa-cluster-role-bind
  namespace: spk-utilities
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: spk-sa-cluster-role
subjects:
- kind: ServiceAccount
  name: spk-service-account
  namespace: spk-utilities

Install the ClusterRoleBinding object:

kubectl apply -f spk-sa-cluster-role-bind.yaml

Verify the ClusterRoleBinding has been created in the cluster:

kubectl get rolebinding -n spk-utilities | grep  spk-sa-cluster-role-bind

In this example, the ClusterRoleBinding named spk-sa-cluster-role-bind has been created, and references the spk-sa-cluster-role.

NAME                    ROLE                     
spk-sa-cluster-role-bind   ClusterRole/spk-sa-cluster-role

Copy the Role object for the service account into a YAML file, and adapt both the metadata.name and metadata.namespace values for your environment:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: spk-sa-role
  namespace: spk-utilities
rules:
- apiGroups:
  - "" # "" indicates the core API group
  resources:
  - pods
  - services
  - services/finalizers
  - endpoints
  - persistentvolumeclaims
  - events
  - configmaps
  - secrets
  verbs:
  - create
  - delete
  - get
  - list
  - patch
  - update
  - watch
  - deletecollection
- apiGroups:
  - apps
  - extensions
  resources:
  - deployments
  - daemonsets
  - replicasets
  - statefulsets
  - ingresses
  verbs:
  - create
  - delete
  - get
  - list
  - patch
  - update
  - watch
- apiGroups:
  - monitoring.coreos.com
  resources:
  - servicemonitors
  verbs:
  - get
  - create
- apiGroups:
  - metrics.k8s.io
  resources:
  - pods
  - nodes
  verbs:
  - get
  - list
  - watch
- apiGroups:
  - k8s.f5net.com
  - dos.k8s.f5net.com
  - dns.k8s.f5net.com
  resources:
  - '*' # asterisk to grant access to all resources of the specified api groups
  verbs:
  - create
  - delete
  - get
  - list
  - patch
  - update
  - watch

Install the Role object:
```
kubectl apply -f spk-sa-role.yaml
```
Verify the Role has been created in the cluster:
```
kubectl get role -n spk-utilities | grep spk-sa-role
```
In this example, the Role named spk-sa-role has been created.
```
spk-sa-role
```

Copy the RoleBinding object into a YAML file, and adapt the subjects.name, subjects.namespace, metadata.name, and metadata.namespace values for your environment:

kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: spk-sa-role-bind
  namespace: spk-utilities
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: spk-sa-role
subjects:
- kind: ServiceAccount
  name: spk-service-account
  namespace: spk-utilities

Install the RoleBinding object:
```
kubectl apply -f spk-sa-role-bind.yaml
```

Verify the RoleBinding has been created in the cluster:

kubectl get rolebinding -n spk-utilities | grep  spk-sa-role-bind

In this example, the RoleBinding named spk-sa-role-bind has been created, and references the spk-sa-role.

NAME               ROLE                     
spk-sa-role-bind   Role/spk-sa-role

Prior to installing the SPK Controller, the following rbac.create and controller.serviceAccount Helm parameters must be configured:

In this example, the serviceAccount value spk-service-account was configured in step 1 of this procedure.
```
rbac:
  create: false

controller:
  create: false
  serviceAccount: spk-service-account
```

User accounts¶

Use these steps to configure and install the objects that allow minimal API access for the cluster user accounts.

Note: The full list of user account RBAC objects can be downloaded here.

Copy the ClusterRole object for the user accounts into a YAML file, and adapt the metadata.name parameter for your environment:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: spk-user-cluster-role
  # "namespace" omitted since ClusterRoles are not namespaced
rules:
- apiGroups:
  - "" # "" indicates the core API group
  resources:
  - namespaces
  - endpoints
  verbs:
  - get
  - list
  - watch
- apiGroups:
  - apiextensions.k8s.io
  resources:
  - customresourcedefinitions
  verbs:
  - get
  - list
  - watch
- apiGroups:
  - admissionregistration.k8s.io
  resources:
  - validatingwebhookconfigurations
  verbs:
  - get
  - create
  - delete

Install the ClusterRole object:

kubectl apply -f spk-user-cluster-role.yaml

Verify the ClusterRole has been created in the cluster:
```
kubectl get clusterrole | grep spk-user-cluster-role
```
In this example, the ClusterRole named spk-user-cluster-role has been created.
```
spk-user-cluster-role
```

Copy the RoleBinding object into YAML file, and adapt the metadata.name, metadata.namespace, and subjects.name values for your environment:

kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: spk-user-clusterrole-bind
  namespace: spk-utilities
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: spk-user-cluster-role
subjects:
- apiGroup: rbac.authorization.k8s.io 
  kind: User  
  name: john.williams
- apiGroup: rbac.authorization.k8s.io 
  kind: User  
  name: mary.jones

Verify the RoleBinding has been created in the cluster:
```
kubectl get rolebinding -n spk-utilities | grep  spk-user-clusterrole-bind
```
In this example, the RoleBinding named spk-user-clusterrole-bind has been created, and references the spk-user-cluster-role.
```
spk-user-clusterrole-bind   ClusterRole/spk-user-cluster-role 
```

Copy the Role object for the user accounts into a YAML file, and adapt the metadata.name and metadata.namespace parameters for your environment:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: spk-user-role
  namespace: spk-utilities
rules:
- apiGroups:
  - "" # "" indicates the core API group
  resources:
  - pods
  - pods/log
  - pods/exec
  - pods/status
  - services
  - services/finalizers
  - endpoints
  - persistentvolumeclaims
  - events
  - configmaps
  - secrets
  - resourcequotas
  verbs:
  - create
  - delete
  - get
  - list
  - patch
  - update
  - watch
  - deletecollection
- apiGroups:
  - apps
  - extensions
  resources:
  - deployments
  - deployments/scale
  - daemonsets
  - replicasets
  - statefulsets
  - ingresses
  verbs:
  - create
  - delete
  - get
  - list
  - patch
  - update
  - watch
- apiGroups:
  - monitoring.coreos.com
  resources:
  - servicemonitors
  verbs:
  - get
  - create
- apiGroups:
  - metrics.k8s.io
  resources:
  - pods
  - nodes
  verbs:
  - get
  - list
  - watch
- apiGroups:
  - k8s.f5net.com
  - dos.k8s.f5net.com
  - dns.k8s.f5net.com
  resources:
  - '*' # asterisk to grant access to all resources of the specified api groups
  verbs:
  - create
  - delete
  - get
  - list
  - patch
  - update
  - watch
- apiGroups:
  - rbac.authorization.k8s.io
  resources:
  - roles
  - rolebindings
  verbs:
  - get
  - watch
  - list
- apiGroups:
  - ""
  resources:
  - serviceaccounts
  verbs:
  - impersonate
  - create
  - delete
  - get
  - list
  - patch
  - update
  - watch

Install the Role object:
```
kubectl apply -f spk-user-role.yaml
```
Verify the Role has been created in the cluster:

In this example, the Role named spk-user-role has been created.
```
kubectl get role -n spk-utilities | grep spk-user-role
```
In this example, the Role named spk-user-role has been created.
```
spk-user-role
```

Copy the RoleBinding into a YAML file, and adapt the metadata.name, and metadata.namespace, and subjects.name parameters for your environment:

kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: spk-user-role-bind
  namespace: spk-utilities
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: spk-user-role
subjects:
- apiGroup: rbac.authorization.k8s.io 
  kind: User  
  name: john.williams
- apiGroup: rbac.authorization.k8s.io 
  kind: User  
  name: mary.jones

Install the RoleBinding object:

kubectl apply -f spk-user-role-bind.yaml

Verify the RoleBinding has been created in the cluster:

kubectl get rolebinding -n spk-gatewway | grep  spk-user-role-bind

In this example, the RoleBinding named spk-user-role-bind has been created, and references the spk-user-role.

NAME                 ROLE                     
spk-user-role-bind   Role/spk-user-role

The specified users can now install the SPK Controller using Helm.

Cluster-wide RBAC for SPK components¶

The RBAC for a majority of the SPK components is currently set to no or minimal cluster-wide access. However, there are a few SPK components that require cluster-wide access, or privileges under certain circumstances. For more information on the SPK components that require cluster-wide access, see Cluster-wide RBACs for SPK.

Next step¶

Continue to one of the following guides listed by installation precedence:

Required: Install the Fluentd Logging collector to centralize SPK container logging.
Optional: Install the dSSM Database to store session-state information.
Required: Install the SPK Controller, Edge Firewall and TMM Pods.

Feedback¶

Provide feedback to improve this document by emailing spkdocs@f5.com.