< Rocky> How to set securityContext seccompProfile type to R StarRocks #questions-and-troubleshooting

Join Slack

<@U0A71G31CDV> How to set securityContext.seccompP...

# questions-and-troubleshooting

Rumit Jain

02/20/2026, 9:01 AM

@Rocky How to set securityContext.seccompProfile.type to "RuntimeDefault" in StarrocksCluster helm chart

Rocky

02/20/2026, 9:01 AM

To set the

securityContext.seccompProfile.type

RuntimeDefault

in the StarRocks Helm chart, you need to configure the

podSpec

field within the FE and BE specifications in your Helm

values.yaml

file. The StarRocks Operator allows you to override or extend the pod specification for each component using the

podSpec

field, which follows the standard Kubernetes PodSpec format. Here is an example of how to configure this in your `my-values.yaml`:

Copy code

yaml
starrocks:
  starrocksFESpec:
    # Standard pod settings for FE
    podSpec:
      securityContext:
        seccompProfile:
          type: RuntimeDefault

  starrocksBeSpec:
    # Standard pod settings for BE
    podSpec:
      securityContext:
        seccompProfile:
          type: RuntimeDefault

  # If you are using Compute Nodes (CN), you should also add it here:
  starrocksCnSpec:
    podSpec:
      securityContext:
        seccompProfile:
          type: RuntimeDefault

How to apply the configuration: 1. Save the configuration above to a file named

my-values.yaml

. 2. Install or upgrade your StarRocks cluster using the Helm command:

Copy code

bash
   helm upgrade --install starrocks starrocks/kube-starrocks -f my-values.yaml

Important Notes: * Pod Level vs. Container Level: The configuration above sets the

securityContext

at the Pod level. If you need to set it specifically for the containers, you would typically use the

containers

field within

podSpec

, but for

seccompProfile

, setting it at the Pod level is the standard practice for applying it to all containers in the pod. * Compatibility: Ensure your Kubernetes cluster version supports the

seccompProfile

field (available since K8s 1.19). * Operator Version: Ensure you are using a recent version of the StarRocks Kubernetes Operator that supports the

podSpec

override field. References • quick_start/helm.md • deployment/environment_configurations.md • administration/management/BE_configuration.md

Rumit Jain

02/20/2026, 11:17 AM

@Rocky Even after adding this:

Copy code

podSpec:
      securityContext:
        seccompProfile:
          type: RuntimeDefault

is still giving the ecurityContext.seccompProfile.type to "RuntimeDefault" in FE pod error. Do I need to setup anything in the operator CRD?

Rocky

02/20/2026, 11:18 AM

To resolve the issue where your

securityContext

configuration isn't being applied to the FE pods, the most likely reason is the field name or its placement in the

StarRocksCluster

resource. In the StarRocks Operator, you should use the podTemplate
field rather than

podSpec

. The

podTemplate

field follows the standard Kubernetes

PodTemplateSpec

structure. 1. Correct YAML Structure Ensure your

StarRocksCluster

custom resource (CR) is configured using

podTemplate

under the

starRocksFeSpec

section. Here is the correct structure:

Copy code

yaml
apiVersion: <http://starrocks.com/v1|starrocks.com/v1>
kind: StarRocksCluster
metadata:
  name: starrockscluster-sample
spec:
  starRocksFeSpec:
    # Use podTemplate, not podSpec
    podTemplate:
      spec:
        securityContext:
          seccompProfile:
            type: RuntimeDefault
        # If your environment requires it at the container level as well:
        containers:
          - name: fe
            securityContext:
              seccompProfile:
                type: RuntimeDefault
              allowPrivilegeEscalation: false
              capabilities:
                drop:
                  - ALL

2. Why "podSpec" might fail The StarRocks Operator CRD defines the sub-component specifications (FE, BE, CN) with a field named

podTemplate

. If you use a key named

podSpec

directly under

starRocksFeSpec

, the operator will likely ignore it because it doesn't recognize that field, resulting in the pods being created with default (possibly empty) security contexts. 3. Do you need to change the Operator CRD? No, you do not need to modify the Operator's CRD (Custom Resource Definition) itself. The existing CRD already supports

podTemplate

. You only need to update your

StarRocksCluster

instance. 4. Common Tips for Restricted Environments If you are running in a restricted environment (like OpenShift or a cluster with "Restricted" Pod Security Admission), you often need to set the context at both the pod and container levels: * Pod level: Handles settings for the entire pod (like

fsGroup

). * Container level: Required for settings like

allowPrivilegeEscalation

capabilities

, and

runAsNonRoot

. Note: If you are using the Helm chart to deploy, make sure you are nesting these values under the correct keys in your

values.yaml

, typically:

Copy code

yaml
starrocks:
  starrocksFESpec:
    podTemplate:
      spec:
        securityContext:
          seccompProfile:
            type: RuntimeDefault

If the error persists after correcting the field name, please check the operator logs (

kubectl logs -n <namespace> <operator-pod-name>

) to see if there are any validation errors when it tries to sync the FE statefulset. References • quick_start/helm.md • deployment/helm.md

Open in Slack

Previous Next