feat: implement cmpd's PolicyRules

apis/apps/v1/cluster_types.go

@@ -404,17 +404,15 @@ type ClusterComponentSpec struct {
 	// This ServiceAccount is used to grant necessary permissions for the Component's Pods to interact
 	// with other Kubernetes resources, such as modifying Pod labels or sending events.
 	//
-	// Defaults:
-	// To perform certain operational tasks, agent sidecars running in Pods require specific RBAC permissions.
-	// The service account will be bound to a default role named "kubeblocks-cluster-pod-role" which is installed together with KubeBlocks.
-	// If not specified, KubeBlocks automatically assigns a default ServiceAccount named "kb-{cluster.name}"
-	//
-	// Future Changes:
-	// Future versions might change the default ServiceAccount creation strategy to one per Component,
-	// potentially revising the naming to "kb-{cluster.name}-{component.name}".
-	//
-	// Users can override the automatic ServiceAccount assignment by explicitly setting the name of
-	// an existed ServiceAccount in this field.
+	// If not specified, KubeBlocks automatically creates a default ServiceAccount named
+	// "kb-{componentdefinition.name}", bound to a role with rules defined in ComponentDefinition's
+	// `policyRules` field. If needed (currently this means if any lifecycleAction is enabled),
+	// it will also be bound to a default role named
+	// "kubeblocks-cluster-pod-role", which is installed together with KubeBlocks.
+	// If multiple components use the same ComponentDefinition, they will share one ServiceAccount.
+	//
+	// If the field is not empty, the specified ServiceAccount will be used, and KubeBlocks will not
+	// create a ServiceAccount. But KubeBlocks does create RoleBindings for the specified ServiceAccount.
 	//
 	// +optional
 	ServiceAccountName string `json:"serviceAccountName,omitempty"`

apis/apps/v1/component_types.go

@@ -175,16 +175,15 @@ type ComponentSpec struct {
 	// This ServiceAccount is used to grant necessary permissions for the Component's Pods to interact
 	// with other Kubernetes resources, such as modifying Pod labels or sending events.
 	//
-	// Defaults:
-	// If not specified, KubeBlocks automatically assigns a default ServiceAccount named "kb-{cluster.name}",
-	// bound to a default role defined during KubeBlocks installation.
-	//
-	// Future Changes:
-	// Future versions might change the default ServiceAccount creation strategy to one per Component,
-	// potentially revising the naming to "kb-{cluster.name}-{component.name}".
-	//
-	// Users can override the automatic ServiceAccount assignment by explicitly setting the name of
-	// an existed ServiceAccount in this field.
+	// If not specified, KubeBlocks automatically creates a default ServiceAccount named
+	// "kb-{componentdefinition.name}", bound to a role with rules defined in ComponentDefinition's
+	// `policyRules` field. If needed (currently this means if any lifecycleAction is enabled),
+	// it will also be bound to a default role named
+	// "kubeblocks-cluster-pod-role", which is installed together with KubeBlocks.
+	// If multiple components use the same ComponentDefinition, they will share one ServiceAccount.
+	//
+	// If the field is not empty, the specified ServiceAccount will be used, and KubeBlocks will not
+	// create a ServiceAccount. But KubeBlocks does create RoleBindings for the specified ServiceAccount.
 	//
 	// +optional
 	ServiceAccountName string `json:"serviceAccountName,omitempty"`

apis/apps/v1/componentdefinition_types.go

@@ -483,8 +483,6 @@ type ComponentDefinitionSpec struct {
 	// for the Component based on the specified policy rules.
 	// This ensures that the Pods in the Component has appropriate permissions to function.
 	//
-	// Note: This field is currently non-functional and is reserved for future implementation.
-	//
 	// This field is immutable.
 	//
 	// +optional

config/crd/bases/apps.kubeblocks.io_clusters.yaml

@@ -5028,19 +5028,16 @@ spec:
                         with other Kubernetes resources, such as modifying Pod labels or sending events.
 
 
-                        Defaults:
-                        To perform certain operational tasks, agent sidecars running in Pods require specific RBAC permissions.
-                        The service account will be bound to a default role named "kubeblocks-cluster-pod-role" which is installed together with KubeBlocks.
-                        If not specified, KubeBlocks automatically assigns a default ServiceAccount named "kb-{cluster.name}"
+                        If not specified, KubeBlocks automatically creates a default ServiceAccount named
+                        "kb-{componentdefinition.name}", bound to a role with rules defined in ComponentDefinition's
+                        `policyRules` field. If needed (currently this means if any lifecycleAction is enabled),
+                        it will also be bound to a default role named
+                        "kubeblocks-cluster-pod-role", which is installed together with KubeBlocks.
+                        If multiple components use the same ComponentDefinition, they will share one ServiceAccount.
 
 
-                        Future Changes:
-                        Future versions might change the default ServiceAccount creation strategy to one per Component,
-                        potentially revising the naming to "kb-{cluster.name}-{component.name}".
-
-
-                        Users can override the automatic ServiceAccount assignment by explicitly setting the name of
-                        an existed ServiceAccount in this field.
+                        If the field is not empty, the specified ServiceAccount will be used, and KubeBlocks will not
+                        create a ServiceAccount. But KubeBlocks does create RoleBindings for the specified ServiceAccount.
                       type: string
                     serviceRefs:
                       description: |-
@@ -13729,19 +13726,16 @@ spec:
                             with other Kubernetes resources, such as modifying Pod labels or sending events.
 
 
-                            Defaults:
-                            To perform certain operational tasks, agent sidecars running in Pods require specific RBAC permissions.
-                            The service account will be bound to a default role named "kubeblocks-cluster-pod-role" which is installed together with KubeBlocks.
-                            If not specified, KubeBlocks automatically assigns a default ServiceAccount named "kb-{cluster.name}"
+                            If not specified, KubeBlocks automatically creates a default ServiceAccount named
+                            "kb-{componentdefinition.name}", bound to a role with rules defined in ComponentDefinition's
+                            `policyRules` field. If needed (currently this means if any lifecycleAction is enabled),
+                            it will also be bound to a default role named
+                            "kubeblocks-cluster-pod-role", which is installed together with KubeBlocks.
+                            If multiple components use the same ComponentDefinition, they will share one ServiceAccount.
 
 
-                            Future Changes:
-                            Future versions might change the default ServiceAccount creation strategy to one per Component,
-                            potentially revising the naming to "kb-{cluster.name}-{component.name}".
-
-
-                            Users can override the automatic ServiceAccount assignment by explicitly setting the name of
-                            an existed ServiceAccount in this field.
+                            If the field is not empty, the specified ServiceAccount will be used, and KubeBlocks will not
+                            create a ServiceAccount. But KubeBlocks does create RoleBindings for the specified ServiceAccount.
                           type: string
                         serviceRefs:
                           description: |-

config/crd/bases/apps.kubeblocks.io_componentdefinitions.yaml

@@ -8366,9 +8366,6 @@ spec:
                   This ensures that the Pods in the Component has appropriate permissions to function.
 
 
-                  Note: This field is currently non-functional and is reserved for future implementation.
-
-
                   This field is immutable.
                 items:
                   description: |-

config/crd/bases/apps.kubeblocks.io_components.yaml

@@ -4800,18 +4800,16 @@ spec:
                   with other Kubernetes resources, such as modifying Pod labels or sending events.
 
 
-                  Defaults:
-                  If not specified, KubeBlocks automatically assigns a default ServiceAccount named "kb-{cluster.name}",
-                  bound to a default role defined during KubeBlocks installation.
-
-
-                  Future Changes:
-                  Future versions might change the default ServiceAccount creation strategy to one per Component,
-                  potentially revising the naming to "kb-{cluster.name}-{component.name}".
+                  If not specified, KubeBlocks automatically creates a default ServiceAccount named
+                  "kb-{componentdefinition.name}", bound to a role with rules defined in ComponentDefinition's
+                  `policyRules` field. If needed (currently this means if any lifecycleAction is enabled),
+                  it will also be bound to a default role named
+                  "kubeblocks-cluster-pod-role", which is installed together with KubeBlocks.
+                  If multiple components use the same ComponentDefinition, they will share one ServiceAccount.
 
 
-                  Users can override the automatic ServiceAccount assignment by explicitly setting the name of
-                  an existed ServiceAccount in this field.
+                  If the field is not empty, the specified ServiceAccount will be used, and KubeBlocks will not
+                  create a ServiceAccount. But KubeBlocks does create RoleBindings for the specified ServiceAccount.
                 type: string
               serviceRefs:
                 description: |-

controllers/apps/component_controller.go

@@ -212,10 +212,8 @@ func (r *ComponentReconciler) setupWithManager(mgr ctrl.Manager) error {
 
 	if viper.GetBool(constant.EnableRBACManager) {
 		b.Owns(&rbacv1.RoleBinding{}).
+			Owns(&rbacv1.Role{}).
 			Owns(&corev1.ServiceAccount{})
-	} else {
-		b.Watches(&rbacv1.RoleBinding{}, handler.EnqueueRequestsFromMapFunc(r.filterComponentResources)).
-			Watches(&corev1.ServiceAccount{}, handler.EnqueueRequestsFromMapFunc(r.filterComponentResources))
 	}
 
 	return b.Complete(r)