ClusterAuthorizationRule

Scope: Cluster

This object manages RBAC and namespace-based authorization.

  • specobject

    Required value

    • spec.accessLevelstring

      Access level:

      • User — has access to information about all objects (including viewing pod logs) but cannot exec into containers, read secrets, and perform port-forwarding;
      • PrivilegedUser — the same as User + can exec into containers, read secrets, and delete pods (and thus, restart them);
      • Editor — is the same as PrivilegedUser + can create and edit namespaces and all objects that are usually required for application tasks;

        Caution! since Editor can edit RoleBindings, he can broader his privileges within the namespace;

      • Admin — the same as Editor + can delete service objects (auxiliary resources such as ReplicaSet, certmanager.k8s.io/challenges, and certmanager.k8s.io/orders);
      • ClusterEditor — the same as Editor + can manage a limited set of cluster-wide objects that can be used in application tasks (ClusterXXXMetric, ClusterRoleBindings, KeepalivedInstance, DaemonSet, etc.). This role is best suited for cluster operators.

        Caution! since ClusterEditor can edit ClusterRoleBindings, he can broader his privileges within the cluster;

      • ClusterAdmin — the same as both ClusterEditor and Admin + can manage cluster-wide service objects (e.g., MachineSets, Machines, OpenstackInstanceClasses…, as well as ClusterAuthorizationRule). This role is best suited for cluster administrators.

        Caution! since ClusterAdmin can edit ClusterRoleBindings, he can broader his privileges within the cluster;

      • SuperAdmin — can perform any actions with any objects (note that limitNamespaces (see below) restrictions remain valid).

      Allowed values: User, PrivilegedUser, Editor, Admin, ClusterEditor, ClusterAdmin, SuperAdmin

      Example:

      accessLevel: PrivilegedUser
      
    • spec.additionalRolesarray of objects

      Additional roles to bind for subjects.

      This parameter is reserved for emergencies. Please, use the accessLevel parameter instead.

      Example:

      additionalRoles:
      - apiGroup: rbac.authorization.k8s.io
        kind: ClusterRole
        name: cluster-write-all
      - apiGroup: rbac.authorization.k8s.io
        kind: ClusterRole
        name: cluster-read-all
      
      • spec.additionalRoles.apiGroupstring

        Required value

        apiGroup for users.

        Example:

        apiGroup: rbac.authorization.k8s.io
        
      • spec.additionalRoles.kindstring

        Required value

        Kind of the role.

        Allowed values: ClusterRole, Role

        Example:

        kind: ClusterRole
        
      • spec.additionalRoles.namestring

        Required value

        Name of the role.

        Example:

        name: cluster-admin
        
    • spec.allowAccessToSystemNamespacesboolean

      Allow access to System namespaces (kube-, d8-, loghouse, default).

      Option available only if enableMultiTenancy option is enabled.

      Default: false

      This feature is available in enterprise edition only.

    • spec.allowScaleboolean

      Defines if scaling of Deployments and StatefulSets is allowed/not allowed.

      Default: false

    • spec.limitNamespacesarray of strings

      List of regex-patterns that define namespaces accessible by the user.

      The decision making process:

      • If the list is defined, then only its constituents are accessible.
      • If the list is not defined, then all namespaces are accessible (except for the system ones - see spec.allowAccessToSystemNamespaces below).

      Option available only if enableMultiTenancy option is enabled.

      This feature is available in enterprise edition only.

      Example:

      limitNamespaces:
      - production-.*
      
      • Element of the arraystring
    • spec.portForwardingboolean

      Allow/disallow the user to do port-forwarding.

      Default: false

    • spec.subjectsarray of objects

      Required value

      Users and/or groups to grant privileges.

      Kubernetes API reference…

      Pay attention to the following nuances if this module is used together with the user-authn module:

      • Use the user’s email as the username to grant privileges to the specific user;
      • When specifying a group, make sure that the necessary groups are allowed to be received from the provider, i.e., they are defined in the corresponding custom resource DexProvider.
      • spec.subjects.kindstring

        Required value

        Type of user identification resource.

        Allowed values: User, Group, ServiceAccount

        Example:

        kind: Group
        
      • spec.subjects.namestring

        Required value

        Resource name.

        Example:

        name: some-group-name
        
      • spec.subjects.namespacestring

        ServiceAccount namespace.

        Pattern: [a-z0-9]([-a-z0-9]*[a-z0-9])?

        Length: 1..63

This object manages RBAC and namespace-based authorization.

  • specobject

    Required value

    • spec.accessLevelstring

      Access level:

      • User — has access to information about all objects (including viewing pod logs) but cannot exec into containers, read secrets, and perform port-forwarding;
      • PrivilegedUser — the same as User + can exec into containers, read secrets, and delete pods (and thus, restart them);
      • Editor — is the same as PrivilegedUser + can create and edit namespaces and all objects that are usually required for application tasks;

        Caution! since Editor can edit RoleBindings, he can broader his privileges within the namespace;

      • Admin — the same as Editor + can delete service objects (auxiliary resources such as ReplicaSet, certmanager.k8s.io/challenges, and certmanager.k8s.io/orders);
      • ClusterEditor — the same as Editor + can manage a limited set of cluster-wide objects that can be used in application tasks (ClusterXXXMetric, ClusterRoleBindings, KeepalivedInstance, DaemonSet, etc.). This role is best suited for cluster operators.

        Caution! since ClusterEditor can edit ClusterRoleBindings, he can broader his privileges within the cluster;

      • ClusterAdmin — the same as both ClusterEditor and Admin + can manage cluster-wide service objects (e.g., MachineSets, Machines, OpenstackInstanceClasses…, as well as ClusterAuthorizationRule). This role is best suited for cluster administrators.

        Caution! since ClusterAdmin can edit ClusterRoleBindings, he can broader his privileges within the cluster;

      • SuperAdmin — can perform any actions with any objects (note that limitNamespaces (see below) restrictions remain valid).

      Allowed values: User, PrivilegedUser, Editor, Admin, ClusterEditor, ClusterAdmin, SuperAdmin

      Example:

      accessLevel: PrivilegedUser
      
    • spec.additionalRolesarray of objects

      Additional roles to bind for subjects.

      This parameter is reserved for emergencies. Please, use the accessLevel parameter instead.

      Example:

      additionalRoles:
      - apiGroup: rbac.authorization.k8s.io
        kind: ClusterRole
        name: cluster-write-all
      - apiGroup: rbac.authorization.k8s.io
        kind: ClusterRole
        name: cluster-read-all
      
      • spec.additionalRoles.apiGroupstring

        Required value

        apiGroup for users.

        Example:

        apiGroup: rbac.authorization.k8s.io
        
      • spec.additionalRoles.kindstring

        Required value

        Kind of the role.

        Allowed values: ClusterRole, Role

        Example:

        kind: ClusterRole
        
      • spec.additionalRoles.namestring

        Required value

        Name of the role.

        Example:

        name: cluster-admin
        
    • spec.allowAccessToSystemNamespacesboolean

      Allow access to System namespaces (kube-, d8-, loghouse, default).

      Option available only if enableMultiTenancy option is enabled.

      Default: false

      This feature is available in enterprise edition only.

    • spec.allowScaleboolean

      Defines if scaling of Deployments and StatefulSets is allowed/not allowed.

      Default: false

    • spec.limitNamespacesarray of strings

      List of regex-patterns that define namespaces accessible by the user.

      The decision making process:

      • If the list is defined, then only its constituents are accessible.
      • If the list is not defined, then all namespaces are accessible (except for the system ones - see spec.allowAccessToSystemNamespaces below).

      Option available only if enableMultiTenancy option is enabled.

      This feature is available in enterprise edition only.

      Example:

      limitNamespaces:
      - production-.*
      
      • Element of the arraystring
    • spec.portForwardingboolean

      Allow/disallow the user to do port-forwarding.

      Default: false

    • spec.subjectsarray of objects

      Required value

      Users and/or groups to grant privileges.

      Kubernetes API reference…

      Pay attention to the following nuances if this module is used together with the user-authn module:

      • Use the user’s email as the username to grant privileges to the specific user;
      • When specifying a group, make sure that the necessary groups are allowed to be received from the provider, i.e., they are defined in the corresponding custom resource DexProvider.
      • spec.subjects.kindstring

        Required value

        Type of user identification resource.

        Allowed values: User, Group, ServiceAccount

        Example:

        kind: Group
        
      • spec.subjects.namestring

        Required value

        Resource name.

        Example:

        name: some-group-name
        
      • spec.subjects.namespacestring

        ServiceAccount namespace.

        Pattern: [a-z0-9]([-a-z0-9]*[a-z0-9])?

        Length: 1..63