Backup CronJob should apply DevWorkspaceOperatorConfig `podSecurityContext`

[rohanKanojia]

Description

DevWorkspaceOperatorConfig documents that config.workspace.podSecurityContext overrides the default PodSecurityContext used for all workspace-related pods created by the DevWorkspace Operator.

devworkspace-operator/apis/controller/v1alpha1/devworkspaceoperatorconfig_types.go

Lines 216 to 219 in 113b402

	// PodSecurityContext overrides the default PodSecurityContext used for all workspace-related
	// pods created by the DevWorkspace Operator. If set, defined values are merged into the default
	// configuration
	PodSecurityContext *corev1.PodSecurityContext `json:"podSecurityContext,omitempty"`

The backup CronJob controller creates a Kubernetes Job (controllers/backupcronjob/backupcronjob_controller.go, createBackupJob) that mounts the workspace PVC but does not set spec.template.spec.securityContext on the pod. Only a minimal container-level securityContext is defined (allowPrivilegeEscalation: false).

devworkspace-operator/controllers/backupcronjob/backupcronjob_controller.go

Lines 433 to 435 in 113b402

	SecurityContext: &corev1.SecurityContext{
	AllowPrivilegeEscalation: ptr.To[bool](false),
	},

On OpenShift clusters where administrators configure a custom podSecurityContext, the main workspace Deployment receives the configured context while backup Jobs may not. That can cause permission or SELinux failures when the backup container reads workspace data from the PVC.

Acceptance Criteria

• Backup Job pod template uses resolved podSecurityContext from DevWorkspaceOperatorConfig when backup CronJob is enabled.
• Behavior is consistent with the workspace Deployment for the same operator configuration.
• Unit test verifies backup Job spec includes configured podSecurityContext.