RBAC

Contents

Overview

This document describes the Kubernetes Role-Based Access Control (RBAC) roles that an operator installation Helm chart automatically creates for you.

The general design goal of the operator installation is to automatically provide the operator with the minimum amount of permissions that the operator requires and to favor built-in roles over custom roles where it makes sense to use the Kubernetes built-in roles.

The operator installation Helm chart automatically creates RBAC ClusterRoles, ClusterRoleBindings, Roles, and RoleBindings for the ServiceAccount that is used by the operator. A running operator assumes that these roles are created in the Kubernetes cluster and will automatically attempt to verify that they are correct when it starts.

Note that the operator installation Helm chart creates ClusterRoles and ClusterRoleBindings when the enableClusterRoleBinding Helm chart configuration setting is set to true (the default), and the chart creates Roles and RoleBindings when the setting is set to false.

References

For more information about:

• Installing the operator, see Prepare for installation and Installation .
• The enableClusterRoleBinding operator Helm chart setting, see Choose a security strategy .
• The Kubernetes ServiceAccount used by the operator, see Service accounts .
• Kubernetes Roles, see the Kubernetes RBAC documentation.

Operator RBAC definitions

To display the Kubernetes Roles and related Bindings used by the operator, where the operator was installed using the Helm release name weblogic-operator, look for the Kubernetes objects, Role, RoleBinding, ClusterRole, and ClusterRoleBinding, when using the Helm status command:

$ helm status weblogic-operator

Assuming the operator was installed into the namespace weblogic-operator-ns with a target namespaces of domain1-ns, the following commands can be used to display a subset of the Kubernetes Roles and related RoleBindings:

$ kubectl describe clusterrole \
  weblogic-operator-ns-weblogic-operator-clusterrole-general

$ kubectl describe clusterrolebinding \
  weblogic-operator-ns-weblogic-operator-clusterrolebinding-general

$ kubectl -n weblogic-operator-ns \
  describe role weblogic-operator-role

$ kubectl -n domain1-ns \
  describe rolebinding weblogic-operator-rolebinding-namespace

Kubernetes Role and RoleBinding naming conventions

The following naming pattern is used for the Role and RoleBinding objects:

• weblogic-operator-<type>-<optional-role-name>

Using:

1. <type> as the kind of Kubernetes object:
   • role
   • rolebinding
2. <optional-role-name> as an optional name given to the Role or RoleBinding
   • For example: namespace

A complete name for an operator created Kubernetes RoleBinding would be:

weblogic-operator-rolebinding-namespace

Kubernetes ClusterRole and ClusterRoleBinding naming conventions

The following naming pattern is used for the ClusterRole and ClusterRoleBinding objects:

• <operator-ns>-weblogic-operator-<type>-<role-name>

Using:

1. <operator-ns> as the namespace in which the operator is installed
   • For example: weblogic-operator-ns
2. <type> as the kind of Kubernetes object:
   • clusterrole
   • clusterrolebinding
3. <role-name> as the name given to the Role or RoleBinding
   • For example: general

A complete name for an operator created Kubernetes ClusterRoleBinding would be:

weblogic-operator-ns-weblogic-operator-clusterrolebinding-general

RoleBindings

Assuming that the operator was installed into the Kubernetes Namespace weblogic-operator-ns, and a target namespace for the operator is domain1-ns, the following RoleBinding entries are mapped to a Role or ClusterRole granting permission to the operator.

ClusterRoleBindings

Assuming that the operator was installed into the Kubernetes Namespace weblogic-operator-ns, the following ClusterRoleBinding entries are mapped to a ClusterRole granting permission to the operator.

NOTE: The operator names in following table represent the <role-name> from the cluster names section.