Anaconda Enterprise dynamically provisions deployments, pods, services, secrets, and ingresses as part of its normal operation. As a result, it is important that the service account utilized by the application be given the necessary permissions to accomplish these operations. For all operations except the ingress controller (more on this below), it is sufficient to grant namespace-specific permissions. The following Role and RoleBinding pair can be used to grant permissions known to be sufficient to cover both installation and regular operation. Replace <SERVICEACCOUNT> and <NAMESPACE> with their appropriate values: 
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: <SERVICEACCOUNT>
  namespace: <NAMESPACE>
rules:
  - verbs:
      - get
      - list
    apiGroups:
      - ''
    resources:
      - namespaces
      - pods/log
      - events
  - verbs:
      - create
      - delete
      - get
      - list
      - patch
      - update
      - watch
    apiGroups:
      - ''
    resources:
      - configmaps
      - secrets
      - pods
      - persistentvolumeclaims
      - endpoints
      - services
  - verbs:
      - create
      - delete
      - get
      - list
      - patch
      - update
      - watch
    apiGroups:
      - apps
    resources:
      - deployments
      - replicasets
      - statefulsets
  - verbs:
      - create
      - delete
      - get
      - list
      - patch
      - update
      - watch
    apiGroups:
      - batch
    resources:
      - jobs
      - cronjobs
  - verbs:
      - create
      - delete
      - get
      - list
      - patch
      - update
      - watch
    apiGroups:
      - extensions
    resources:
      - deployments
      - replicasets
  - verbs:
      - create
      - delete
      - get
      - list
      - patch
      - update
      - watch
    apiGroups:
      - networking.k8s.io
    resources:
      - ingresses
  - verbs:
      - create
      - delete
      - get
      - list
      - patch
      - update
      - watch
    apiGroups:
      - route.openshift.io
    resources:
      - routes
      - routes/custom-host
  - verbs:
      - get
      - list
    apiGroups:
      - ''
    resources:
      - serviceaccounts
      - roles
  ---
  apiVersion: rbac.authorization.k8s.io/v1
  kind: RoleBinding
  metadata:
    name: <SERVICEACCOUNT>
    namespace: <NAMESPACE>
  roleRef:
    apiGroup: rbac.authorization.k8s.io
    kind: Role
    name: <SERVICEACCOUNT>
  subjects:
    - kind: ServiceAccount
      name: <SERVICEACCOUNT>
If you wish to use the Anaconda-supplied ingress, it is also necessary to grant a small number of additional, cluster-wide permissions. That is because, as is typical with ingress controllers, this controller expects to be able to monitor ingress-related resources across all namespaces. The following is a minimal ClusterRole and ClusterRoleBinding pair that has been demonstrated to grant the ingress controller sufficient permissions to run without warnings: 
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: <SERVICEACCOUNT>-ingress
rules:
  - verbs:
      - '*'
    apiGroups:
      - '*'
    resources:
      - ingressclasses
  - verbs:
      - patch
    apiGroups:
      - '*'
    resources:
      - events
  - verbs:
      - list
      - watch
    apiGroups:
      - '*'
    resources:
      - secrets
      - endpoints
      - ingresses
      - services
      - pods
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: <SERVICEACCOUNT>-ingress
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: <SERVICEACCOUNT>-ingress
subjects:
  - kind: ServiceAccount
    name: <SERVICEACCOUNT>
    namespace: <NAMESPACE>
Please review these RBAC settings with your Kubernetes administrators. It is possible they can be further reduced, but no assumption should be made to that effect. Certainly, significant reductions in the scope of these permissions is likely to prevent correct operation of Anaconda Enterprise.