Bamboo installation using Helm chart fails to create a Kubernetes pod

関連コンテンツ

  • 関連コンテンツがありません

お困りですか?

アトラシアン コミュニティをご利用ください。

コミュニティに質問

プラットフォームについて: Data Center - この記事は、Data Center プラットフォームのアトラシアン製品に適用されます。

このナレッジベース記事は製品の Data Center バージョン用に作成されています。Data Center 固有ではない機能の Data Center ナレッジベースは、製品のサーバー バージョンでも動作する可能性はありますが、テストは行われていません。サーバー*製品のサポートは 2024 年 2 月 15 日に終了しました。サーバー製品を利用している場合は、アトラシアンのサーバー製品のサポート終了のお知らせページにて移行オプションをご確認ください。

*Fisheye および Crucible は除く

要約

Deploying Bamboo on an OpenShift Kubernetes cluster using Helm Chart fails to spin up a pod. An error message appears when describing the StatefulSet, stating: "create Pod <pod_name> in StatefulSet <statefulset_name> failed error: pods "<pod_name>" is forbidden: unable to validate against any security context constraint"

環境

The solution has been tested in the following environments:

  • Bamboo Data Center versions 9.4.0 and 9.5.1

  • Red Hat Openshift Container Platform version 4.12 and 4.14

診断

After attempting to deploy the Bamboo instance using the helm install  command, it was observed that no Kubernetes pod was coming up for a long time. Then, running the command below showed that the statefulset never reached a ready state. 

$ oc get statefulset

From the output below, look out for the Bamboo's instance statefulset:

NAME        		READY   AGE
<statefulset_name>   0/1     85m

The next step was to describe the statefulset, kindly substitute the name of your particular statefulset.

The following error message was seen when describing the statefulset using the command below:

$ oc describe statefulsets <statefulset_name>

From the output, we can see the message under the Events

Events:
  Type     Reason        Age                  From                    Message
  ----     ------        ----                 ----                    -------
  Warning  FailedCreate  116s (x28 over 71m)  statefulset-controller  create Pod <pod_name> in StatefulSet <statefulset_name> failed error: pods "<pod_name>" is forbidden: unable to validate against any security context constraint: [provider "anyuid": Forbidden: not usable by user or serviceaccount, provider restricted-v2: .spec.securityContext.fsGroup: Invalid value: []int64{2005}: 2005 is not an allowed group, spec.initContainers[0].securityContext.runAsUser: Invalid value: 0: must be in the ranges: [1000700000, 1000709999], provider "restricted": Forbidden: not usable by user or serviceaccount, provider "nonroot-v2": Forbidden: not usable by user or serviceaccount, provider "nonroot": Forbidden: not usable by user or serviceaccount, provider "hostmount-anyuid": Forbidden: not usable by user or serviceaccount, provider "machine-api-termination-handler": Forbidden: not usable by user or serviceaccount, provider "hostnetwork-v2": Forbidden: not usable by user or serviceaccount, provider "hostnetwork": Forbidden: not usable by user or serviceaccount, provider "hostaccess": Forbidden: not usable by user or serviceaccount, provider "lvms-vgmanager": Forbidden: not usable by user or serviceaccount, provider "lvms-topolvm-node": Forbidden: not usable by user or serviceaccount, provider "node-exporter": Forbidden: not usable by user or serviceaccount, provider "privileged": Forbidden: not usable by user or serviceaccount]

原因

When designing a Docker image using a Dockerfile, you have the option to set the UserID that will be used to execute the application. In this case, Bamboo and the group Bamboo are designed to use the UID and GID of 2005. However when a pod is deployed into an OpenShift namespace, especially by a Kubernetes non-admin user, OpenShift will assign available UIDs and GIDs from a chosen range. This range can be viewed using the command below:

$ oc describe namespace bamboo-project
Name:                   bamboo-project
Created:                5 days ago
Labels:                 kubernetes.io/metadata.name=bamboo-project
                        pod-security.kubernetes.io/audit=baseline
                        pod-security.kubernetes.io/audit-version=v1.24
                        pod-security.kubernetes.io/warn=baseline
                        pod-security.kubernetes.io/warn-version=v1.24
Annotations:            openshift.io/description=
                        openshift.io/display-name=
                        openshift.io/requester=bamboo_dev
                        openshift.io/sa.scc.mcs=s0:c26,c25
                        openshift.io/sa.scc.supplemental-groups=1000700000/10000
                        openshift.io/sa.scc.uid-range=1000700000/10000

The supplemental groups are regular Linux group IDs that OpenShift enforces SELinux discretionary access control on. Since the GID 2005 is not within the allowed range in the namespace, the pod will be prevented from instantiation.

ソリューション

There are two possible solutions to this issue.

Solution 1 (Recommended)

Remove these lines below or comment them out in the Helm's values.yaml file as seen below

  # Standard K8s field that holds pod-level security attributes and common container settings.
  # https://kubernetes.io/docs/tasks/configure-pod-container/security-context/
  # Do not populate when deploying to OpenShift, unless anyuid policy is attached to a service account.

  # -- Whether to apply security context to pod.
  #
  #securityContextEnabled: true

  #securityContext:

    # -- The GID used by the Bamboo docker image
    # GID will default to 2005 if not supplied and securityContextEnabled is set to true.
    # This is intended to ensure that the shared-home volume is group-writeable by the GID used by the Bamboo container.
    # However, this doesn't appear to work for NFS volumes due to a K8s bug: https://github.com/kubernetes/examples/issues/260
    #
    #fsGroup: 2005

Also ensure that the openshift.runWithRestrictedSCC to true in the Helm values file as shown below:

openshift:
  runWithRestrictedSCC: true

Now carry out a fresh installation with the modified Helm's values file.

Solution 2 (anyUID SCC)

The first option will be to create a service account for this Helm Installation and assign the SCC permissions to the service account.

$ oc create serviceaccount bamboo-sa
serviceaccount/bamboo-sa created

Then proceed to add the required SCC to the service account named bamboo-sa, please feel free to use your service account name.

Now add the necessary permissions and roles to the service account 
$ oc adm policy add-scc-to-user anyuid -z bamboo-sa
clusterrole.rbac.authorization.k8s.io/system:openshift:scc:anyuid added: "bamboo-sa"

Now modify the Helm's value file as shown below:

# K8s ServiceAccount configuration. Give fine-grained identity and authorization
# to Pods
#
serviceAccount:

  # -- Set to 'true' if a ServiceAccount should be created, or 'false' if it
  # already exists.
  #
  create: false

  # -- The name of the ServiceAccount to be used by the pods. If not specified, but
  # the "serviceAccount.create" flag is set to 'true', then the ServiceAccount name
  # will be auto-generated, otherwise the 'default' ServiceAccount will be used.
  # https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/#use-the-default-service-account-to-access-the-api-server
  #
  name: bamboo-sa

Now carry out a fresh installation with the modified Helm's values file.




最終更新日 2024 年 6 月 4 日

この内容はお役に立ちましたか?

はい
いいえ
この記事についてのフィードバックを送信する

関連コンテンツ

  • 関連コンテンツがありません
Powered by Confluence and Scroll Viewport.