As more organizations standardize on Kubernetes platforms, application deployments are expected to fit within enterprise security policies from the start. For Siebel Cloud Manager (SCM), that means giving administrators the flexibility to run SCM, Siebel, and Observability (Metrics Monitoring and Log Analytics) resources in ways that align with Kubernetes security controls across different distributions, including OpenShift, whether Kubernetes is deployed in a customer’s data center on premises or in the cloud.

In monthly Update 26.6, Siebel Cloud Manager has been enhanced to allow SCM, Siebel, and Observability resources to run using a customer-provided user ID in a Kubernetes cluster. This supports a least-privilege model through:

  • Any UID support: Run resources using a customer-specified user ID.
  • No privileged mode: Avoid privileged container execution.
  • No root execution: Prevent containers from running as root.
  • Restricted security posture: Use restricted settings wherever possible.
  • Non-default service accounts: Avoid use of default service accounts.

In practical terms, this helps organizations adopt stronger deployment security while running in CNCF-certified Kubernetes environments on distributions such as OKE on OCI, OCNE, OpenShift, and others.

Why this matters

Organizations can standardize deployments more easily when applications adapt to controlled Kubernetes environments.

  • Security teams: Can require enterprise applications to avoid unnecessary privileges, reduce root-based execution, and follow platform-approved runtime policies.
  • Platform teams: Can apply a more consistent operating model across Kubernetes distributions, whether Kubernetes runs on premises or in the cloud.
  • Business and operations teams: Can reduce security exceptions, simplify platform alignment, and fit Siebel Cloud Manager deployments into existing governance processes.

Broader Kubernetes impact

The 26.6 enhancement is designed to help SCM, Siebel, and Observability resources run with custom runtime identities in Kubernetes environments where customers need greater control over user IDs, group IDs, and filesystem permissions.

For Kubernetes environments such as OKE on OCI and OCNE, the value is operational consistency. Administrators can use the same security-context-driven approach to align runtime identity, storage ownership, and deployment behavior with their organization’s Kubernetes standards. This gives teams a more portable model for secure SCM deployment across Kubernetes distributions in customer-managed data centers or cloud environments.

What changes

The provisioning payload now supports a security_context section for Siebel and Observability resources. This provides explicit control over container execution user and group IDs.

  • Administrators can define:
    • Runtime user
    • Runtime group
    • Filesystem group
  • If no custom security context is provided:
    • The system uses default runtime identity values.
    • On OpenShift, default mode uses standard UID/GID values.
  • In enhanced security mode:
    • Administrators identify namespace-specific identity ranges.
    • Those values are passed through SCM configuration and the Siebel or Observability payload.
    • The deployment can better align with customer-controlled platform policies.

A secure-by-default model for OpenShift

OpenShift security for SCM, Siebel, Observability, and image builder deployments follows a restricted-by-default model with explicit, auditable exceptions.

  • SCM: SCM runs under restricted-v2, uses the scm-service-account, and aligns Cloud Manager application pods and setup jobs with OpenShift’s hardened default security posture.
  • Siebel runtime and Observability (Metrics Monitoring and Log Analytics): Most Siebel runtime and Observability components also run under restricted-v2, including SAI, CGW, SMC, SES edge, Traefik, Prometheus, OpenSearch dashboards, log aggregation, database monitoring, validators, and controllers.
  • These workloads use constrained service accounts, namespace isolation, and least-privilege execution.

Controlled elevated access where required

Some platform components require elevated Security Context Constraints for specific operational reasons.

  • Flux controllers use nonroot-v2.
  • Node exporters use the node-exporter SCC.
  • Node log collectors use hostmount-anyuid.
  • OpenSearch and selected Siebel services use anyuid.

These exceptions are scoped to specific needs such as GitOps reconciliation, node metrics collection, host log collection, storage and runtime compatibility, or legacy UID behavior. The goal is not to broaden access across the deployment, but to provide the minimum required flexibility for workloads that cannot operate correctly under the default restricted posture.

Image builder security

The image builder job requires a custom nonroot-builder SCC. This SCC remains non-privileged and blocks host networking, host PID and IPC access, host ports, HostPath volumes, and privileged containers.

It allows only builder-specific runtime flexibility, including RunAsAny user and group behavior and controlled privilege escalation. The nonroot-builder SCC should be bound only to the image builder service account.

Operational considerations

Before enabling enhanced security, administrators should prepare SCM, Siebel filesystem, migration, and Observability storage locations so file ownership and permissions match the selected runtime identity.

  • Default mode is simpler and uses standard runtime identity values.
  • Enhanced security provides tighter alignment with platform controls.
  • For Observability, additional storage preparation may be needed when Prometheus uses local storage.
  • In non-OpenShift Kubernetes environments, the same security context parameters help administrators align runtime identity and filesystem access with their platform’s security and storage requirements.
  • These considerations apply across customer Kubernetes deployments, whether the cluster is hosted on premises in a customer’s data center or in a cloud environment.

End-user experience

For administrators and business stakeholders, the result is a more secure and flexible deployment experience across Kubernetes environments.

  • Most workloads can run with restricted permissions.
  • Elevated permissions, where required, are limited to specific components and service accounts.
  • OpenShift SCC usage is visible, reviewable, and auditable through standard OpenShift commands.
  • Non-OpenShift deployments benefit from the same custom user and group ID flexibility without requiring OpenShift-specific SCC configuration.
  • Organizations gain more control over how SCM resources run in Kubernetes while supporting least-privilege deployment practices across enterprise environments.

Conclusion

Together, these updates help Siebel CRM deployments managed by Siebel Cloud Manager feel more at home in modern Kubernetes environments, giving teams the flexibility to meet their security standards without adding unnecessary complexity.