AdminJob

The AdminJob Custom Resource Definition (CRD) allows administrators to run AIStor Client (mc) commands against an AIStor cluster using declarative Kubernetes YAML configurations. Each command runs in a Kubernetes Job pod that is authenticated with the specified ServiceAccount and STS credentials.

• Kubernetes ServiceAccount with PolicyBinding - Create a ServiceAccount and bind it to appropriate policies using the PolicyBinding CRD. The ServiceAccount provides the identity, while the PolicyBinding grants permissions.
• Existing AIStor Object Store deployment - AdminJob targets an existing ObjectStore cluster.

This minimal example uses AdminJob to create a bucket named my-bucket in the primary-object-store cluster using the consoleAdmin policy for full administrative access. Save the following YAML as adminjob-quickstart.yaml to get started:

---
apiVersion: v1
kind: ServiceAccount
metadata:
  name: minio-job
  namespace: primary-object-store
---
apiVersion: sts.min.io/v1beta1
kind: PolicyBinding
metadata:
  name: minio-job
  namespace: primary-object-store
spec:
  application:
    serviceaccount: minio-job
    namespace: primary-object-store
  policies:
    - consoleAdmin
---
apiVersion: aistor.min.io/v1alpha1
kind: AdminJob
metadata:
  name: create-bucket-job
  namespace: primary-object-store
spec:
  serviceAccountName: minio-job
  objectStore:
    name: primary-object-store
    namespace: primary-object-store
  commands:
    - op: make-bucket
      args:
        name: my-bucket

Apply the configuration:

kubectl apply -f adminjob-quickstart.yaml

Check the status:

kubectl get adminjob create-bucket-job
kubectl describe adminjob create-bucket-job

AdminJob executes AIStor Client commands through Kubernetes Jobs with flexible configuration options.

AdminJob supports two methods for defining commands. Structured commands use the op (operation) field with args for common operations such as creating buckets, managing users and policies, and configuring object store settings. For operations not covered by structured commands, custom commands use the command field to specify arbitrary AIStor Client commands with full control over arguments and flags.

AdminJob automatically configures an alias named myminio that references the target object store, which structured commands use internally. Custom commands can reference this alias directly.

AdminJob supports two execution modes: sequential and parallel. In sequential mode (the default), commands execute one after another in order. In parallel mode, commands execute concurrently. When using parallel execution, use the dependsOn field to define command dependencies and control execution order.

AdminJob provides two strategies for handling command failures. The default continueOnFailure strategy continues executing remaining commands even if earlier commands fail. The stopOnFailure strategy stops execution at the first command failure.

spec:
  failureStrategy: stopOnFailure

Commands can access environment variables from Secrets using env or envFrom, and files from ConfigMaps or Secrets using volumeMounts and volumes. Use these mechanisms to provide credentials, configuration files, or policy documents to commands.

AdminJob resources report their status through the overall job phase and individual command results. Use kubectl describe adminjob <name> to view the current status and command results, or see Viewing Job logs for detailed output.

The overall job phase progresses through the following states, ending in either Success or Failed:

Each command within the AdminJob reports its individual results and output messages. When commands fail, AdminJob provides specific failure information to help diagnose issues.

Configure the ttlSecondsAfterFinished field to automatically delete completed AdminJob resources after a specified time period. The TTL controller deletes the AdminJob and its associated Kubernetes Jobs after they reach a terminal state (Success or Failed).

spec:
  ttlSecondsAfterFinished: 3600  # Delete after 1 hour

Use TTL configuration for one-time setup tasks, scheduled operations with CronJobs, or general resource management to prevent accumulation of completed Jobs. Without TTL configuration, AdminJob resources persist indefinitely and must be manually deleted using kubectl delete.

This example demonstrates creating two users with credentials stored in Kubernetes Secrets. It shows two different approaches for injecting secret values as environment variables.

The envFrom approach loads all keys from a Secret as environment variables. Use this when you need multiple values from the same Secret. The env approach selects specific keys from a Secret. Use this for more granular control over which values to inject.

The following YAML document creates three resources.

1. The first creates a secret with a single password.
2. The second creates a Secret with multiple credentials, both a username and a password.
3. The third creates two users. daniel uses credentials from the Secret containing both username and password. pedro uses the credential from the Secret with just a password.

# Secret with individual credentials - Stores a single password
apiVersion: v1
kind: Secret
metadata:
  name: user-password
  namespace: primary-object-store
data:
  PASSWORD: cGVkcm8xMjM=  # echo -n 'pedro123' | base64
---
# Secret with multiple credentials - Stores username and password
apiVersion: v1
kind: Secret
metadata:
  name: user-credentials
  namespace: primary-object-store
data:
  USER: ZGFuaWVs         # echo -n 'daniel' | base64
  PASSWORD: ZGFuaWVsMTIz # echo -n 'daniel123' | base64
---
# AdminJob with user creation commands
apiVersion: aistor.min.io/v1alpha1
kind: AdminJob
metadata:
  name: create-users-job
  namespace: primary-object-store
spec:
  serviceAccountName: minio-job
  objectStore:
    name: primary-object-store
    namespace: primary-object-store
  commands:
    # Create user using envFrom to load all secret keys as environment variables
    - name: add-user-daniel
      op: admin/user/add
      args:
        user: $(USER)
        password: $(PASSWORD)
      envFrom:
        - secretRef:
            name: user-credentials
    # Create user using env to load specific secret key
    - name: add-user-pedro
      op: admin/user/add
      args:
        user: pedro
        password: $(PASSWORD)
      env:
        - name: PASSWORD
          valueFrom:
            secretKeyRef:
              name: user-password
              key: PASSWORD

This example demonstrates a complete policy workflow. It creates a bucket, adds users, creates a policy from a ConfigMap, and attaches that policy to the users.

The workflow uses parallel execution mode to run commands concurrently when possible. The dependsOn field establishes dependencies that ensure policy attachments wait for both user creation and policy creation to complete. A policy document stored in a ConfigMap is mounted into the command container at /policies/bucket-policy.json.

The following YAML creates two resources that perform actions in the following order:

1. Create the policy.
2. Create the bucket and users in parallel.
3. Attach the policy to the users once the above dependencies are satisfied.

# ConfigMap with policy document
apiVersion: v1
kind: ConfigMap
metadata:
  name: custom-policies
  namespace: primary-object-store
data:
  bucket-policy.json: |
    {
      "Version": "2012-10-17",
      "Statement": [
        {
          "Effect": "Allow",
          "Action": ["s3:*"],
          "Resource": [
            "arn:aws:s3:::data-bucket",
            "arn:aws:s3:::data-bucket/*"
          ]
        }
      ]
    }    
---
# AdminJob with dependencies
apiVersion: aistor.min.io/v1alpha1
kind: AdminJob
metadata:
  name: policy-workflow-job
  namespace: primary-object-store
spec:
  serviceAccountName: minio-job
  objectStore:
    name: primary-object-store
    namespace: primary-object-store
  execution: parallel
  commands:
    # Create bucket
    - name: create-bucket
      op: make-bucket
      args:
        name: data-bucket
    # Create users (can run in parallel with bucket creation)
    - name: create-user-alice
      op: admin/user/add
      args:
        user: alice
        password: alice-secure-password
    - name: create-user-bob
      op: admin/user/add
      args:
        user: bob
        password: bob-secure-password
    # Create policy from ConfigMap
    - name: create-policy
      op: admin/policy/create
      args:
        name: data-bucket-access
        policy: /policies/bucket-policy.json
      volumeMounts:
        - name: policies
          mountPath: /policies
      volumes:
        - name: policies
          configMap:
            name: custom-policies
            items:
              - key: bucket-policy.json
                path: bucket-policy.json
    # Attach policy to alice (depends on user and policy creation)
    - name: attach-policy-alice
      op: admin/policy/attach
      dependsOn:
        - create-user-alice
        - create-policy
      args:
        policy: data-bucket-access
        user: alice
    # Attach policy to bob (depends on user and policy creation)
    - name: attach-policy-bob
      op: admin/policy/attach
      dependsOn:
        - create-user-bob
        - create-policy
      args:
        policy: data-bucket-access
        user: bob

This example demonstrates using custom commands for operations not covered by structured commands. Custom commands provide full control over AIStor Client arguments and flags.

This example creates a bucket with versioning enabled and then checks its status.

The following YAML creates one resource that adds a bucket named versioned-data on the object store called primary-object-store. The bucket starts with versioning enabled.

apiVersion: aistor.min.io/v1alpha1
kind: AdminJob
metadata:
  name: custom-commands-job
  namespace: primary-object-store
spec:
  serviceAccountName: minio-job
  objectStore:
    name: primary-object-store
    namespace: primary-object-store
  commands:
    # Create bucket with versioning enabled using custom command
    - name: create-versioned-bucket
      command:
        - mc
        - mb
        - --with-versioning
        - myminio/versioned-data
    # Check bucket status using custom command
    - name: check-bucket-status
      command:
        - mc
        - stat
        - myminio/versioned-data

*Either op or command is required for each command.

The following operations are supported when using the op field:

For other AIStor Client commands, use the command field with a custom command array.

For complete CRD specification details, see the AdminJob CRD documentation.