Building Images Using OCI Connector in K8S Job
Before reading, please refer to The General Logic of Using the OCI Connector Proxy in K8S Workload
TOC
Feature Overview
This article will guide you on how to use the OCI Connector to build images within a Kubernetes Job
and push them to a Registry. With the capabilities of the OCI Connector, ordinary users can operate without needing to touch or configure authentication credentials, thereby maximizing the security of these credentials.
When using the OCI Connector within a Kubernetes Job, the following key points should be noted:
- Change the address of the target image being built to the connector's proxy address. What is the Connector Proxy Address
- For example: harbor.example.cn/test/abc -> harbor.default.cluster.local/test/abc
- Mount the configuration provided by the Connector.
- Configure
insecure registry
for the client tools.
This article will take buildkitd
as an example and detail the process of creating a Kubernetes Job to complete the image building and pushing utilizing the OCI Connector
, without the need to configure authentication information on the client side.
Prerequisites
- Create a Connector.
- A Dockerfile for building the image.
Connector
kubectl apply -f - <<EOF
apiVersion: connectors.alauda.io/v1alpha1
kind: Connector
metadata:
name: harbor
spec:
address: https://harbor.example.com # Replace with an accessible OCI registry address
auth:
name: tokenAuth
params:
- name: repository
value: testing/busybox
secretRef:
name: harbor-secret
connectorClassName: oci
---
apiVersion: v1
stringData: # Replace with actual authentication information
password: admin
username: admin
kind: Secret
metadata:
name: harbor-secret
type: cpaas.io/distribution-registry-token
EOF
Dockerfile
To demonstrate the building and pushing process, we need to prepare a Dockerfile. To simplify the operation, we will store the content of the Dockerfile in a ConfigMap and mount it to the Pod using a Kubernetes Pod volume.
kubectl apply -f - <<EOF
apiVersion: v1
kind: ConfigMap
metadata:
name: dockerfile
data:
Dockerfile: |
FROM scratch
LABEL maintainer="example@example.com"
WORKDIR /app
ENV APP_VERSION="1.0.0"
EOF
Operational Steps
Creating the K8S Job
- To utilize the connector's proxy capabilities, we need to inject the authentication information required by the proxy into
docker/config.json
. A volume must be provided to mount docker/config.json
.
- To allow the client to access the HTTP proxy, we need to configure
insecure-registries
for the client. A volume must be provided to mount buildkitd.toml
.
- Modify the address of the pushed image to the connector's proxy address.
For information on obtaining the Connector's proxy address, see: OCI Connector Class Proxy Information Description
The Job content is as follows:
cat << EOF | kubectl create -f -
kind: Pod
apiVersion: v1
metadata:
generateName: buildkit-build-
spec:
restartPolicy: Never
containers:
- name: buildkit
image: docker-mirrors.alauda.cn/moby/buildkit:v0.18.2
securityContext:
privileged: true
env:
- name: BUILDKITD_FLAGS
value: "--config /etc/buildkit/buildkitd.toml"
command:
- /bin/sh
- -c
args:
- |
set -ex
buildctl-daemonless.sh --debug \
build \
--progress=plain \
--frontend=dockerfile.v0 \
--opt filename=Dockerfile \
--local context=/workspace \
--local dockerfile=/workspace \
--output type=image,name=c-harbor.default.svc.cluster.local/test/test-cjt:v1,push=true \
--export-cache type=inline
volumeMounts:
- name: dockerfile
mountPath: /workspace
- name: docker-config
mountPath: /root/.docker
- name: buildkitd-config
mountPath: /etc/buildkit
volumes:
# Mounting the dockerfile to the Pod
- name: dockerfile
configMap:
name: dockerfile
# Mounting docker's config.json to the Pod
- name: docker-config
csi:
readOnly: true
driver: connectors-csi
volumeAttributes:
connector.name: "harbor"
configuration.names: "docker-config"
# Mounting buildkitd.toml to the Pod
- name: buildkitd-config
csi:
readOnly: true
driver: connectors-csi
volumeAttributes:
connector.name: "harbor"
configuration.names: "buildkitd"
EOF
Operational Results
You can check whether the Job has executed successfully with the following command:
Summary
We have completed the entire process of "Building Images Using OCI Connector in K8S Job." We can observe that during the execution of the Job, users are required to specify the authentication information for the image repository, and within the Pod running the Job, users cannot access the authentication data configured for the Connector. This greatly ensures that credentials are not leaked in practical usage, safeguarding the security of the tool's authentication information.