http://starrocks.io logo
Join Slack
Powered by
Hey <@U0A71G31CDV> I need to ensure that a secur...
# questions-and-troubleshooting
j
Hey @Rocky I need to ensure that a secure image that runs on nonroot user can read the log/storage on my CN , how to add the equivalent of the following via CRDS in K8s to the CN? securityContext: fsGroup: 65532 fsGroupChangePolicy: OnRootMismatch
r
To ensure your secure non-root image can read the log/storage on your Compute Node (CN), you can add the 
podSecurityContext
field to the 
starRocksCnSpec
section of your 
StarRocksCluster
CRD. In the StarRocks Kubernetes Operator, pod-level security settings (like 
fsGroup
) are defined under the 
podSecurityContext
field for each component. Configuration Example Add the following to your 
StarRocksCluster
YAML:
Copy code
yaml
apiVersion: <http://starrocks.com/v1|starrocks.com/v1>
kind: StarRocksCluster
metadata:
  name: starrocks-cluster
spec:
  starRocksCnSpec:
    # Pod-level security context
    podSecurityContext:
      fsGroup: 65532
      fsGroupChangePolicy: "OnRootMismatch"
    
    # Optional: If you also need container-level settings
    # securityContext:
    #   runAsUser: 65532
    #   runAsNonRoot: true
    
    image: starrocks/cn-ubuntu:latest # Replace with your secure image
    # ... other CN configurations (requests, limits, storage, etc.)
Key Details: * 
podSecurityContext
: This field maps directly to the Kubernetes 
PodSecurityContext
. It applies to the entire Pod, ensuring that volumes (like logs and storage) are mounted with the correct group permissions so your non-root user can access them. * 
fsGroupChangePolicy
: Setting this to 
OnRootMismatch
ensures that Kubernetes only attempts to change permissions if the root of the volume doesn't already match the 
fsGroup
, which helps avoid slow startup times on large volumes. * Version Note: This structure is supported in recent versions of the StarRocks Operator (v1.8.x and later). If you are using an older version, ensure your CRD definition includes these fields. For more details on available fields, you can refer to the official StarRocks Operator API documentation. References • administration/management/FE_configuration.md • quick_start/helm.md • administration/user_privs/authentication/security_integration.md
j
@Rocky the CRDS doesn't have a podSecurityContext definition
r
If you are using a version of the StarRocks Operator that does not have 
podSecurityContext
in the CRD (likely an older version), you should first check if your Operator is at least v1.9.0 or later. Support for 
podSecurityContext
and granular container 
securityContext
was expanded in recent releases. In the latest versions of the StarRocks Kubernetes Operator, you can add these settings directly to the 
starRocksCnSpec
(or `starRocksBeSpec`/`starRocksFeSpec`) using the 
podSecurityContext
field. Configuration for StarRocksCluster CRD (v1.9.0+) Add the following under your CN specification:
Copy code
yaml
apiVersion: <http://starrocks.com/v1|starrocks.com/v1>
kind: StarRocksCluster
metadata:
  name: starrocks-cluster
spec:
  starRocksCnSpec:
    # This field maps to the Kubernetes PodSecurityContext
    podSecurityContext:
      fsGroup: 65532
      fsGroupChangePolicy: "OnRootMismatch"
    
    # Standard container-level settings
    securityContext:
      runAsUser: 65532
      runAsNonRoot: true
      capabilities:
        drop:
          - ALL
If your CRD is older If your current CRD does not support the 
podSecurityContext
field, you have two options: 1. Upgrade the Operator and CRD: This is the recommended path. Download the latest CRD and Operator manifests from the StarRocks Operator GitHub releases.
Copy code
bash
    kubectl apply -f <https://raw.githubusercontent.com/StarRocks/starrocks-kubernetes-operator/main/deploy/starrocks.com_starrocksclusters.yaml>
2. Use Helm (if applicable): If you are using the 
kube-starrocks
Helm chart, ensure you are using chart version v1.9.x or higher. In the 
values.yaml
, you can specify these under:
Copy code
yaml
    starrocksCnSpec:
      podSecurityContext:
        fsGroup: 65532
        fsGroupChangePolicy: "OnRootMismatch"
Why use 
fsGroup
? * Permission Mapping: When 
fsGroup
is set, Kubernetes mounts the volume and changes the group ownership of all files to the specified ID. This allows your non-root user (running with that group) to read/write to the log and storage paths. * Startup Speed: 
fsGroupChangePolicy: "OnRootMismatch"
is crucial for large storage volumes, as it prevents Kubernetes from recursively `chown`ing the entire volume on every restart if the permissions already match. References • deployment/sr_operator.md • quick_start/helm.md • StarRocks Operator API Documentation (GitHub) References • administration/user_privs/group_provider.md • deployment/shared_data/s3.md • deployment/shared_data/gcs.md
j
r
You are correct that in some versions and the documentation (like the 
api.md
summary), the 
podSecurityContext
field may not be explicitly listed at the top level of the component specification. However, based on the StarRocks Kubernetes Operator source code and recent updates (v1.10+), the operator supports mapping these security settings to the generated Pods. If 
podSecurityContext
is missing from your CRD If you have verified that your current CRD schema does not include 
podSecurityContext
, you have two primary options: 1. Add fields directly to the component spec In some versions of the operator, the security settings are flattened or specifically named. Check if your CRD allows the following fields directly under `starRocksCnSpec`: * 
runAsUser
* 
fsGroup
For example:
Copy code
yaml
starRocksCnSpec:
  fsGroup: 65532
  # Note: fsGroupChangePolicy might not be available as a direct field in older CRDs
2. Upgrade to the latest CRD The 
podSecurityContext
field was explicitly added to support arbitrary pod-level security settings (including 
fsGroupChangePolicy
). If your 
starrocks.com_starrocksclusters.yaml
does not have it, it is recommended to pull the latest version directly from the GitHub repository's 
main
branch, as release YAMLs sometimes lag behind the actual implementation. You can update your CRD with:
Copy code
bash
kubectl apply -f <https://raw.githubusercontent.com/StarRocks/starrocks-kubernetes-operator/main/deploy/starrocks.com_starrocksclusters.yaml>
Once updated, you can use the following structure:
Copy code
yaml
apiVersion: <http://starrocks.com/v1|starrocks.com/v1>
kind: StarRocksCluster
metadata:
  name: starrocks-cluster
spec:
  starRocksCnSpec:
    # This field maps to the Pod's .spec.securityContext
    podSecurityContext:
      fsGroup: 65532
      fsGroupChangePolicy: "OnRootMismatch"
    # This field maps to the CN container's .spec.securityContext
    securityContext:
      runAsUser: 65532
      runAsNonRoot: true
Why you need this for CN StarRocks Compute Nodes (CN) often mount volumes for logs (
/opt/starrocks/cn/log
) and temporary storage. * 
fsGroup
: Ensures the mounted volumes are owned by the specified GID, allowing your non-root user to read/write. * 
fsGroupChangePolicy: "OnRootMismatch"
: This is highly recommended for StarRocks because it avoids the slow recursive 
chown
process on volume mounts if the permissions are already correct, significantly speeding up Pod startup times. Summary of field availability * 
fsGroup
: Usually available directly in 
starRocksCnSpec
in v1.8+. * 
podSecurityContext
: Introduced to allow full 
PodSecurityContext
objects (including 
fsGroupChangePolicy
) in v1.10+. If you still don't see these fields after updating the CRD, it is possible that your environment is using a cached or older version of the schema. You can verify the available fields on your cluster using:
Copy code
bash
kubectl explain starrockscluster.spec.starRocksCnSpec
References • deployment/sr_operator.md • administration/user_privs/authentication/security_integration.md • StarRocks Operator GitHub - Issue #120 (OpenShift/Security Context)
2 Views
Open in Slack
PreviousNext
Powered by