このコンテンツは選択した言語では利用できません。

Chapter 12. Using buildah-ns Tekton task


The buildah-ns Tekton task builds Open Container Initiative (OCI) images without requiring a container runtime daemon, such as the Docker daemon. The task uses buildah and applies user namespace isolation to provide enhanced security.

After a successful build, the task produces the following results:

  • The fully qualified image name
  • The SHA256 digest of the image

The buildah-ns task is functionally the same as the standard buildah Tekton task, but applies additional security mechanisms to improve container isolation at the kernel level.

12.1. Differences between buildah and buildah-ns tasks

The buildah-ns task extends the standard buildah task with the following security-focused changes:

  • Task name: The task name is buildah-ns instead of buildah.
  • Annotations: The task includes security annotations that enable automatic user namespace mapping:

    io.kubernetes.cri-o.userns-mode: "auto"
    io.openshift.builder: "true"
  • Security model: User namespace separation improves privilege isolation. This limits the impact of container escape vulnerabilities.

12.2. Security model of the buildah-ns task

The buildah-ns task uses user namespace isolation to separate privileges between containers and the host system.

When the task runs with namespace annotations, the system maps user IDs (UIDs) as follows:

  • Inside the container: Processes run as UID 0, which is displayed as the root user.
  • Outside the container: The same processes run as a nonzero UID on the host system.

This mapping lets container processes behave as root while restricting their host-level privileges.

User namespace isolation provides the following security advantages:

  • kernel-level isolation: Adds an extra isolation boundary between containers.
  • Reduced privilege exposure: Limits the impact of compromised workloads by running them as non-root users on the host.
  • Container escape protection: Helps mitigate potential vulnerabilities that allow escaping from the container runtime environment.

12.3. Workspaces, parameters, and results for the buildah-ns task

The buildah-ns task requires a workspace and accepts several parameters to customize image builds. The task results contain information about the built image.

12.3.1. Workspace

Expand
NameRequiredDescription

source

Yes

The build context for the container image. Typically has application source code and a Containerfile or Dockerfile.

12.3.2. Parameters

Expand
NameTypeDefaultDescription

IMAGE

string

Required

Fully qualified name of the image to build, including tag.

CONTAINERFILE_PATH

string

Containerfile

Path to the container build file relative to the source workspace.

TLS_VERIFY

string

true

Verify TLS when pushing images. Red Hat recommends true.

VERBOSE

string

false

Enables verbose build output.

SUBDIRECTORY

string

.

Subdirectory in the workspace to use as the build context.

STORAGE_DRIVER

string

overlay

Storage driver for Buildah. Align with the cluster node configuration.

BUILD_EXTRA_ARGS

string

Empty

Additional flags for the Buildah build command.

PUSH_EXTRA_ARGS

string

Empty

Additional flags for the Buildah push command.

SKIP_PUSH

string

false

Set to true to skip pushing the image to the registry.

12.3.3. Results

Expand
NameDescription

IMAGE_URL

Fully qualified name of the built image.

IMAGE_DIGEST

SHA256 digest of the built image.

12.4. Running the buildah-ns task

You can run the buildah-ns task as part of a PipelineRun resource.

Procedure

  1. Create a YAML file that defines PipelineRun object:

    Example pipeline-run.yaml file

    apiVersion: tekton.dev/v1
    kind: PipelineRun
    metadata: {}
    spec:
      pipelineRef:
        name: task-buildah-ns
      params:
        - name: IMAGE
          value: your-image-name
        - name: TLS_VERIFY
          value: true
        - name: VERBOSE
          value: false
      workspaces:
        - name: source
          persistentVolumeClaim:
            claimName: your-pvc-name

    value
    Replace your-image-name with the full name of the container image that you want to build.
    claimName

    Replace your-pvc-name with the name of the PersistentVolumeClaim (PVC) that stores the application source code.

    Note

    If the target container registry requires authentication, configure a Kubernetes secret for registry access and link it to the service account that runs the TaskRun or PipelineRun resources.

  2. Create the PipelineRun resource by applying the YAML file:

    $ oc apply -f pipeline-run.yaml
Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。 最新の更新を見る.

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

Theme

© 2026 Red Hat
トップに戻る