Required RBAC permissions
editRequired RBAC permissions
editInstalling and running ECK, as well as using ECK-managed resources requires certain Kubernetes permissions. These permissions are listed below, with a reason why they are needed.
Installing CRDs
editThis permission is required to install CRDs. CRDs (CustomResourceDefinitions) are the only non-namespaced resources required to be installed.
| Name | API group | Optional? | Usage |
|---|---|---|---|
|
|
no |
Extend Kubernetes APIs with Elastic Stack application resources. |
Installing the ECK operator
editThese permissions are required to install the ECK operator in a Kubernetes cluster.
| Name | API group | Optional? | Usage |
|---|---|---|---|
|
|
no |
The ECK operator can be either deployed as a StatefulSet or as a Deployment. |
|
|
no |
Service account that the operator Pods run as. |
|
|
no |
Role bound to the operators Service account. Depending on the installation type (global/restricted) either a global (ClusterRole) or a namespaced (Role) resource is needed. |
|
|
no |
Binding between the operators role and the operators service account. Depending on the installation type (global/restricted), either global (ClusterRoleBinding) or namespaced (RoleBinding) resource is needed. |
|
|
yes |
Configuration parameters of the Operator. They can be specified directly in the StatefulSet (or Deployment) resource instead. |
|
|
yes |
Namespace where the operator will run. It can be a pre-existing namespace as well. |
|
|
yes |
Validating webhook installation. It provides fast feedback for the user directly as a APIServer response. A subset of these validations is also run by the operator itself, but the results are only available through operator logs and Kubernetes events. Check docs for more. |
|
|
yes |
Secret containing the validating webhook’s endpoint CA certificate. |
|
|
yes |
Service for validating webhook endpoint. |
And all permissions that Running ECK operator section specifies.
Running ECK operator
editThese permissions are needed by the Service Account that ECK operator runs as.
| Name | API group | Optional? | Usage |
|---|---|---|---|
|
no |
Assuring expected Pods presence during Elasticsearch reconciliation, safely deleting Pods during configuration changes and validating |
|
|
no |
Checking availability of service endpoints. |
|
|
no |
Emitting events concerning reconciliation progress and issues. |
|
|
no |
Expanding existing volumes. Check docs to learn more. |
|
|
no |
Reading/writing configuration, passwords, certificates, and so on. |
|
|
no |
Creating Services fronting Elastic Stack applications. |
|
|
no |
Reading/writing configuration. |
|
|
|
no |
Deploying Elasticsearch |
|
|
no |
Deploying Kibana, APM Server, EnterpriseSearch, Maps, Beats or Elastic Agent. |
|
|
no |
Deploying Beats or Elastic Agent. |
|
|
no |
Ensuring update safety for Elasticsearch. Check docs to learn more. |
|
|
yes |
Validating storage expansion support. Check docs to learn more. |
|
|
yes |
Controlling access between referenced resources. Check docs to learn more. |
And all permissions that the Using ECK-managed resources chapter specifies.
Using ECK-managed resources
editThese permissions are needed to manage each Elastic Stack application. For example, to create, update and delete Elasticsearch clusters the permissions for the respective verbs must be held by the user that performs the operation.
| Name | API group | Optional? |
|---|---|---|
|
|
no |
|
|
no |
|
|
no |
|
|
no |
|
|
no |
|
|
no |
|
|
no |