## The problem I ran into: “green” builds that later explode
I recently helped wire a CI/CD pipeline for a distributed cloud platform, and everything looked perfect at first: unit tests passed, image builds finished, deployments went out… and then the application would occasionally fail in production with behavior that didn’t match the commit that was supposedly deployed.

The weird part was that rerunning the same pipeline sometimes produced different container images even when the Dockerfile hadn’t changed. That’s the kind of issue that earns the nickname **Heisenbug**: when you try to observe it (rerun builds), it seems to “change its nature.”

After tracing it, the root cause was a subtle one: our CI built Docker images with changing dependency artifacts (think: package indexes, lockfiles not actually pinned, npm installs with registry variability). Even worse, the build logs didn’t clearly tell us *which exact dependency content* produced each image.

So I built a deterministic **CI gate** that blocks deployments unless the produced Docker image corresponds to the exact dependency content we expect—using **content-addressed Docker layers** and a manifest signature checked during the pipeline.

---

## What this gate enforces (in plain terms)
Here’s the idea I implemented:

1. CI builds the Docker image.
2. CI computes a “fingerprint” of the *dependency inputs* (lockfiles + Dockerfile + build args that affect dependencies).
3. CI compares that fingerprint to what the image claims about its layers (content-addressing).
4. If there’s a mismatch, the pipeline fails before deploy.

This turns “we think the image is right” into “the image is proven to match the exact inputs.”

### Two important terms (briefly)
- **Docker layer content-addressing**: Docker identifies layers by the content they contain (not just by step order). If dependency inputs change, the produced layer hashes change.
- **CI gate**: an explicit step in the pipeline that must pass validation before moving on to deploy.

---

## The pipeline pieces I used
I used AWS CodeBuild (it runs containerized builds) and a Docker build flow that produces a manifest we can inspect. The gate runs after the build but before pushing (or before allowing deploy).

### High-level flow
- Checkout code
- Compute input fingerprint
- Build Docker image
- Inspect the image manifest for layer digests
- Verify that the manifest matches the fingerprint expectations
- Fail pipeline if not

---

## Step 1: Add a dependency fingerprint to your repo
I keep this file in the repo at `ci/dependency-fingerprint.sh`. It computes a SHA256 over:
- `Dockerfile`
- any lockfiles (example includes `package-lock.json`, `requirements.txt`, `poetry.lock`)
- selected build args (in this example: `BASE_IMAGE`, `PYTHON_VERSION`)

```bash
#!/usr/bin/env bash
set -euo pipefail

# Collect dependency inputs that affect what gets installed into the image.
# The goal is: same inputs => same fingerprint.
fingerprint_sources=(
  "Dockerfile"
  "package-lock.json"
  "requirements.txt"
  "poetry.lock"
)

# Only include files that exist (repo may not have all lockfiles).
tmp_list="$(mktemp)"
for f in "${fingerprint_sources[@]}"; do
  if [[ -f "$f" ]]; then
    echo "$f" >> "$tmp_list"
  fi
done

# Include key build args explicitly.
# These must match the CI build args.
base_image="${BASE_IMAGE:-}"
python_version="${PYTHON_VERSION:-}"

# Produce deterministic output by hashing filenames + file contents.
sha_input="$(cat "$tmp_list")|BASE_IMAGE=${base_image}|PYTHON_VERSION=${python_version}"

content_hash="$(
  # sha256sum output includes filename; use awk to keep just hashes for stability
  {
    # hash file content in stable order
    while IFS= read -r file; do
      sha256sum "$file" | awk '{print $1}'
    done < "$tmp_list"
    # hash the build args
    echo -n "${base_image}" | sha256sum | awk '{print $1}'
    echo -n "${python_version}" | sha256sum | awk '{print $1}'
  } | sha256sum | awk '{print $1}'
)"

rm -f "$tmp_list"

# Write fingerprint for later steps to consume
echo "$content_hash"
```

**Why this works:** It makes the pipeline compute a deterministic hash from the exact dependency inputs. If a lockfile changes or build args change, the fingerprint changes.

---

## Step 2: Build and capture layer digests (the “proof”)
Next I built the verifier `ci/verify-image-proof.sh`. It:
- reads expected fingerprint
- builds the image locally
- extracts layer digests from the image manifest
- derives a manifest proof hash
- compares it to the expected fingerprint

```bash
#!/usr/bin/env bash
set -euo pipefail

# Expected fingerprint computed earlier
expected_fingerprint="${EXPECTED_FINGERPRINT:?EXPECTED_FINGERPRINT env var required}"

# The image name we will build
image_ref="${IMAGE_REF:-local/proof-image:ci}"

# Build args that must match how fingerprint was computed
build_args=()
if [[ -n "${BASE_IMAGE:-}" ]]; then
  build_args+=(--build-arg "BASE_IMAGE=${BASE_IMAGE}")
fi
if [[ -n "${PYTHON_VERSION:-}" ]]; then
  build_args+=(--build-arg "PYTHON_VERSION=${PYTHON_VERSION}")
fi

# Build the image.
# We don't push yet; this is just to get a manifest we can inspect.
docker build \
  -t "${image_ref}" \
  "${build_args[@]}" \
  -f Dockerfile .

# Get the manifest in a portable format.
# This uses Docker's inspect to obtain layer digests deterministically.
manifest_json="$(docker image inspect "${image_ref}" --format '{{json .}}')"

# Extract layer digest-like identifiers.
# Note: docker image inspect .RootFS.Layers contains layer IDs used by Docker.
# Those are content-addressed identifiers derived from the build.
layers="$(
  echo "$manifest_json" | python3 -c '
import json,sys
obj=json.load(sys.stdin)
layers=obj.get("RootFS",{}).get("Layers",[])
print("\n".join(layers))
'
)"

# Hash the layer identifiers to get a reproducible "manifest proof"
manifest_proof="$(
  printf "%s\n" "$layers" | sha256sum | awk '{print $1}'
)"

echo "Expected fingerprint: ${expected_fingerprint}"
echo "Manifest proof:      ${manifest_proof}"

if [[ "$manifest_proof" != "$expected_fingerprint" ]]; then
  echo "ERROR: Image manifest proof does not match dependency fingerprint."
  echo "This blocks deploy to prevent Heisenbugs."
  exit 1
fi

echo "Image proof verified successfully."
```

**Why this is strict:** even if the build finishes and tests pass, the pipeline refuses to proceed unless the image’s internal layer identity matches the dependency fingerprint. That forces determinism at the artifact level.

---

## Step 3: Wire it into AWS CodeBuild (buildspec.yml)
Here’s a working `buildspec.yml` for CodeBuild that:
- installs tooling (Python for JSON extraction)
- computes the fingerprint
- builds and verifies the image proof
- only then pushes or deploys

Replace `REPOSITORY_URI` and `IMAGE_TAG` to match your setup.

```yaml
version: 0.2

env:
  variables:
    IMAGE_REF: "local/proof-image:ci"
    IMAGE_TAG: "latest"
  # These should be set in CodeBuild project env or via build parameters
  # BASE_IMAGE: "python:3.12-slim"
  # PYTHON_VERSION: "3.12"

phases:
  install:
    runtime-versions:
      python: 3.11
    commands:
      - echo "Installing dependencies (if any)..."
      - which python3
      - python3 --version
      - docker --version

  pre_build:
    commands:
      - echo "Computing dependency fingerprint..."
      - chmod +x ci/dependency-fingerprint.sh ci/verify-image-proof.sh
      - export EXPECTED_FINGERPRINT="$(./ci/dependency-fingerprint.sh)"
      - echo "Fingerprint: ${EXPECTED_FINGERPRINT}"

  build:
    commands:
      - echo "Building image and verifying content-addressed layer proof..."
      - ./ci/verify-image-proof.sh

  post_build:
    commands:
      - echo "Verification passed."
      # Optional: push only after gate passes
      # - aws ecr get-login-password --region $AWS_REGION | docker login --username AWS --password-stdin $REPOSITORY_URI
      # - docker tag "${IMAGE_REF}" "${REPOSITORY_URI}:${IMAGE_TAG}"
      # - docker push "${REPOSITORY_URI}:${IMAGE_TAG}"

artifacts:
  files: []
```

**What happens when this runs:**
- `dependency-fingerprint.sh` hashes your dependency inputs.
- `verify-image-proof.sh` builds the image and computes a proof hash from layer identifiers.
- If proof doesn’t match, CodeBuild exits with a non-zero status → pipeline stops → deployment never happens.

---

## Step 4: Make Docker builds actually deterministic
The gate helps detect nondeterminism, but to avoid false failures, I also tightened Docker builds.

In practice, I used a Dockerfile pattern that pins versions and prefers lockfiles. Example Dockerfile:

```dockerfile
# syntax=docker/dockerfile:1
ARG BASE_IMAGE=python:3.12-slim
FROM ${BASE_IMAGE}

ARG PYTHON_VERSION=3.12

WORKDIR /app

# Copy lockfiles first to maximize reproducibility
COPY package-lock.json ./package-lock.json
COPY requirements.txt ./requirements.txt
COPY poetry.lock ./poetry.lock 2>/dev/null || true

# Install dependencies in a deterministic way.
# Examples assume you use lockfiles for both npm and pip/poetry.
RUN python --version
RUN pip install --no-cache-dir -r requirements.txt

# Application code
COPY . .

CMD ["python", "-c", "print('app running')"]
```

**Key point:** the fingerprint assumes that these inputs drive the layers that get installed. If your Dockerfile fetches dependencies dynamically without lockfiles, the gate will correctly detect a mismatch—sometimes after tests pass.

---

## Debugging when the gate trips (what I learned)
When I saw failures, the fastest way to understand them was:

- Compare the dependency fingerprint values between two runs.
- Inspect the built image’s layer identifiers (`docker image inspect ... RootFS.Layers`).
- Check for hidden sources of variability:
  - unpinned apt/apk package versions
  - package managers hitting indexes that change resolution without lockfiles
  - build args that silently change between pipeline runs

This approach turned mystery nondeterminism into measurable evidence.

---

## Conclusion
I implemented a deterministic CI/CD gate for AWS CodeBuild that blocks deployments when a built Docker image’s content-addressed layer identifiers don’t match a fingerprint computed from dependency inputs. By combining input hashing with manifest-derived “proof,” I traded occasional production Heisenbugs for a hard, reproducible validation step—so artifact integrity becomes something the pipeline can enforce, not something we hope is true.

A Deterministic Ci/Cd Gate For Aws Codebuild That Blocks “Heisenbugs” Via Content-Addressed Docker Layers

## The problem I ran into: “same PR” but different infrastructure drift

I was building a platform engineering workflow for ephemeral **review apps** (short-lived app environments spun up per pull request). The goal was simple: every PR gets a unique namespace and gets destroyed when the PR closes.

But after a few days, I noticed something weird in production-adjacent test environments:

- the same PR URL sometimes pointed to a different deployment
- side effects (config maps, feature flags, caches) didn’t line up deterministically
- debugging was maddening because “refreshing” didn’t mean “same world”

The cause ended up being subtle: we were generating names from mutable signals (like timestamps or local counters). Even if the PR stayed the same, the app identity could drift.

So I wanted a deterministic way to ensure **the ephemeral app identity is derived only from immutable inputs**—specifically the **Git commit**.

---

## The niche solution: namespace + Helm release names from a Git commit digest

Kubernetes namespaces and Helm release names can be based on strings, but Kubernetes has naming constraints (DNS labels). Also, Helm release names can’t be arbitrarily long.

So I implemented a tiny identity scheme:

- Compute a **SHA-256 digest** from the Git commit SHA.
- Convert it to a DNS-label-safe value.
- Use it to form:
  - namespace: `pr-<digest>`
  - Helm release: `rev-<digest>`

That means:
- the same commit always maps to the same namespace/release
- a different commit maps to a different namespace/release
- teardown becomes deterministic and idempotent

---

## What happens when the pipeline runs (end-to-end)

When CI runs for a PR:

1. CI exports `GIT_COMMIT_SHA` (the immutable commit identifier).
2. The pipeline computes `DIGEST` from it.
3. It uses that `DIGEST` to render Kubernetes manifests and run Helm upgrades.
4. The “destroy” job uses the same digest to delete the exact namespace.

No drift, no guessing.

---

## Step 1: Compute a DNS-safe digest (with code)

I used Python in CI because it’s portable and explicit about what it does.

```python
#!/usr/bin/env python3
import hashlib
import re
import sys

def dns_label_safe(s: str, max_len: int = 20) -> str:
    """
    Convert any string into a lowercase DNS-label-safe token:
    - lowercase letters, digits, and hyphens
    - trim to max_len
    """
    s = s.lower()
    # Replace invalid chars with hyphen
    s = re.sub(r'[^a-z0-9-]', '-', s)
    # Collapse consecutive hyphens
    s = re.sub(r'-{2,}', '-', s).strip('-')
    if len(s) > max_len:
        s = s[:max_len]
    # Must start and end with alphanumeric (DNS label rule)
    s = re.sub(r'^[^a-z0-9]+', '', s)
    s = re.sub(r'[^a-z0-9]+$', '', s)
    return s or "x"

def commit_digest(commit_sha: str) -> str:
    """
    Deterministically map a commit SHA to a short token.
    """
    sha_bytes = commit_sha.encode("utf-8")
    digest = hashlib.sha256(sha_bytes).hexdigest()  # 64 hex chars
    # Use first N chars as stable identity. 20 hex chars => 20 length.
    token = digest[:20]
    return dns_label_safe(token, max_len=20)

if __name__ == "__main__":
    if len(sys.argv) != 2:
        print("Usage: digest.py <GIT_COMMIT_SHA>", file=sys.stderr)
        sys.exit(2)

    commit = sys.argv[1].strip()
    token = commit_digest(commit)
    print(token)
```

### Why this works
- SHA-256 output is deterministic for the same input.
- Taking the first 20 hex chars gives a short, stable token.
- DNS label safety ensures Kubernetes accepts the names.

---

## Step 2: Use the digest in Kubernetes namespace and Helm release names

Kubernetes **namespace names** are DNS labels: lowercase letters, digits, hyphens; and they must fit length rules.

Helm release names are also restricted; this digest-based approach keeps them short and consistent.

### CI variables (example)

```bash
export GIT_COMMIT_SHA="a3f1c2d8e4b7f0c2a6e5f1f4d3c2b1a090877665"

DIGEST="$(python3 digest.py "$GIT_COMMIT_SHA")"
NAMESPACE="pr-${DIGEST}"
RELEASE="rev-${DIGEST}"
echo "NAMESPACE=$NAMESPACE"
echo "RELEASE=$RELEASE"
```

At this point:
- every run for the same commit produces the same `NAMESPACE` and `RELEASE`
- a teardown can safely delete the correct namespace

---

## Step 3: Deterministic Helm release values wiring

I used a minimal Helm values pattern: the chart reads the commit identity and uses it to label resources and set environment variables.

### `values.yaml` template (generated in CI)

```yaml
app:
  commitSha: "{{ GIT_COMMIT_SHA }}"
  identity: "{{ DIGEST }}"
service:
  name: "api"
image:
  tag: "{{ GIT_COMMIT_SHA }}"
```

In CI, I render these values (example using `envsubst` style; simplest for small teams):

```bash
cat > values.yaml <<EOF
app:
  commitSha: "${GIT_COMMIT_SHA}"
  identity: "${DIGEST}"
service:
  name: "api"
image:
  tag: "${GIT_COMMIT_SHA}"
EOF
```

### Helm command

```bash
helm upgrade --install "$RELEASE" ./charts/myapp \
  --namespace "$NAMESPACE" \
  --create-namespace \
  -f values.yaml
```

This is the part that usually causes drift when names vary; with digest-derived names, it becomes stable.

---

## Step 4: Idempotent “destroy” job (the missing piece)

Drift becomes especially painful at cleanup time. So I made teardown deterministic too.

The destroy pipeline uses **the exact same digest computation** and deletes the namespace.

```bash
export GIT_COMMIT_SHA="$GIT_COMMIT_SHA_FROM_PIPELINE"
DIGEST="$(python3 digest.py "$GIT_COMMIT_SHA")"
NAMESPACE="pr-${DIGEST}"

# Namespace deletion is idempotent-ish: it’s safe to run multiple times.
kubectl delete namespace "$NAMESPACE" --ignore-not-found=true
```

This guarantees:
- the destroy job doesn’t accidentally remove a different PR’s environment
- repeated runs don’t flap unpredictably

---

## Optional hardening I added: label everything with the identity

When debugging, I wanted “find all resources belonging to this review app” without depending on naming alone.

So I added consistent labels:
- `review.identity=<DIGEST>`
- `review.commit=<short-sha>`

In Helm templates, you’d apply these labels to Deployment/Service/Ingress/etc. Example snippet:

```yaml
metadata:
  labels:
    review.identity: "{{ .Values.app.identity }}"
    review.commit: "{{ .Values.app.commitSha | trunc 7 }}"
```

### Why labels matter
Helm and Kubernetes resources can be renamed or have different kinds, but labels give you a single filter for observability and cleanup tooling.

---

## Concrete example: what I observed in logs

Before the digest approach, two CI runs for the same PR could create different namespaces due to a timestamp component. That caused:

- Ingress pointed to a new Service, but old workloads still existed.
- Retrying deploy didn’t “replace”; it created.

After switching to `pr-<sha-digest>`:
- both CI runs reported the same namespace/release
- the Helm upgrade updated the existing Deployment instead of creating a sibling environment
- namespace deletion consistently removed exactly one review app universe

---

## FinOps and platform engineering angle (why this matters beyond correctness)

This identity scheme reduced waste in two ways:

1. **No orphan review environments**  
   Deterministic teardown dramatically lowered “forgotten namespaces” that keep pulling images and running background jobs.

2. **Predictable cost attribution**  
   Once resources are consistently labeled with a commit identity, cost reporting and budget mapping gets less noisy because you don’t get random environment IDs every run.

---

## Closing summary

I implemented deterministic ephemeral review apps by deriving Kubernetes namespace and Helm release names from a SHA-256 digest of the immutable Git commit SHA. This removed identity drift, made Helm upgrades replace the correct resources, and enabled idempotent cleanup by deleting the exact namespace tied to the commit digest—turning chaotic per-PR environments into stable, debuggable, cost-controlled infrastructure.

Deterministic Ephemeral Review Apps By Git Commit Digest In Kubernetes

I ran into a weird CI/CD failure that looked like an “auth problem,” but it wasn’t. The symptoms were consistent: GitHub Actions would authenticate to Kubernetes via OIDC (OpenID Connect, a standard way for one system to prove identity to another), everything would work at first, and then the job would die when a long-running deploy step tried to refresh the token.

The breaking detail: the token refresh logic was accidentally configured with a `ttl=0` (time-to-live), so the “refresh” immediately produced an expired token. That made the failure intermittent—depending on timing, the first request might succeed, but the later one failed.

Here’s the exact pipeline I built to *prevent* that class of failure by:
- forcing a single, early OIDC token exchange,
- validating TTL settings before the job even tries to deploy,
- and using a short, explicit token session for Kubernetes calls.

### The failure mode I observed (and how I reproduced it)

In my setup, the deploy step ran long enough that Kubernetes client calls needed a fresh token. When TTL was mis-set to `0`, the refresh returned an unusable token.

I reproduced it conceptually like this (not Kubernetes-specific, just the idea):

```python
import time

def fake_refresh(ttl_seconds: int):
    now = int(time.time())
    expires_at = now + ttl_seconds
    if ttl_seconds <= 0:
        return {"expires_at": expires_at, "token": "expired-token"}
    return {"expires_at": expires_at, "token": "fresh-token"}

for ttl in [0, 30]:
    result = fake_refresh(ttl)
    now = int(time.time())
    ok = result["expires_at"] > now
    print(f"ttl={ttl} expires_at={result['expires_at']} ok={ok} token={result['token']}")
```

When `ttl=0`, `expires_at` is not in the future, so the token is instantly expired. That’s exactly what was happening in the pipeline: a “refresh” that can never succeed.

### The fix: fail fast on invalid TTL and avoid refresh mid-deploy

Instead of letting refresh happen during the deployment (which makes debugging painful), I enforced two guardrails:

1. **Validate TTL config at the beginning of the job**  
2. **Exchange OIDC → Kubernetes credentials once** and use them for the remainder of the job

Below is a working GitHub Actions workflow that does that.

### Working GitHub Actions workflow (OIDC to Kubernetes with TTL validation)

This example assumes:
- You use GitHub’s OIDC federation with a Kubernetes cluster that trusts the GitHub identity.
- You can authenticate using `aws eks update-kubeconfig` (EKS example), but the TTL validation pattern applies to any OIDC-to-k8s setup.

Create `.github/workflows/deploy.yml`:

```yaml
name: Deploy with OIDC and TTL guard

on:
  workflow_dispatch:
  push:
    branches: ["main"]

permissions:
  id-token: write   # required for OIDC
  contents: read

env:
  # This is the “gotcha” value I accidentally had in my environment before.
  # It MUST be > 0 for any refresh-like logic to make sense.
  DEPLOY_TOKEN_TTL_SECONDS: "300"

jobs:
  deploy:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout
        uses: actions/checkout@v4

      - name: Validate TTL before any Kubernetes auth
        shell: bash
        run: |
          set -euo pipefail
          ttl="${DEPLOY_TOKEN_TTL_SECONDS}"

          if ! [[ "$ttl" =~ ^[0-9]+$ ]]; then
            echo "DEPLOY_TOKEN_TTL_SECONDS must be a non-negative integer. Got: $ttl"
            exit 1
          fi

          if [ "$ttl" -le 0 ]; then
            echo "ERROR: DEPLOY_TOKEN_TTL_SECONDS must be > 0. Got: $ttl"
            exit 1
          fi

          echo "TTL looks good: $ttl seconds"

      - name: Authenticate to cloud (example: AWS EKS)
        uses: aws-actions/configure-aws-credentials@v4
        with:
          role-to-assume: arn:aws:iam::123456789012:role/github-oidc-deploy-role
          aws-region: us-east-1

      - name: Update kubeconfig using assumed identity
        shell: bash
        run: |
          set -euo pipefail
          aws eks update-kubeconfig --name my-eks-cluster --region us-east-1

      - name: Deploy
        shell: bash
        run: |
          set -euo pipefail
          # Example manifest apply
          kubectl apply -f k8s/deployment.yaml
          kubectl rollout status deployment/my-app --timeout=120s
```

#### What each block does (and why it matters)

- `permissions: id-token: write`  
  Enables GitHub Actions OIDC token issuance. Without it, OIDC auth can’t happen.

- `Validate TTL before any Kubernetes auth`  
  This is the key safety belt. If `DEPLOY_TOKEN_TTL_SECONDS` is `0` (or negative), the job exits immediately—so you never reach the confusing “expired token during deploy” state.

- `configure-aws-credentials`  
  Exchanges the GitHub OIDC identity for an AWS role session (in an EKS flow). This is the “one-time exchange” concept.

- `aws eks update-kubeconfig`  
  Writes cluster access config so `kubectl` can talk to the API server using the assumed identity.

- `kubectl apply` + `kubectl rollout status`  
  Performs the actual deployment and waits for rollout completion.

### A tiny TTL unit test that saved me later

I also added a little script to make TTL validation consistent across repos. It’s simple, but it prevents copy/paste mistakes.

Create `scripts/validate-ttl.py`:

```python
import os
import sys

def validate_ttl(ttl_str: str) -> int:
    if not ttl_str.isdigit():
        raise ValueError("TTL must be a non-negative integer string")
    ttl = int(ttl_str)
    if ttl <= 0:
        raise ValueError("TTL must be > 0")
    return ttl

if __name__ == "__main__":
    ttl_str = os.environ.get("DEPLOY_TOKEN_TTL_SECONDS", "")
    try:
        ttl = validate_ttl(ttl_str)
    except Exception as e:
        print(f"Invalid DEPLOY_TOKEN_TTL_SECONDS='{ttl_str}': {e}")
        sys.exit(1)
    print(f"TTL OK: {ttl} seconds")
```

Then call it in the workflow instead of the bash check:

```yaml
      - name: Validate TTL before any Kubernetes auth (python)
        shell: bash
        run: |
          set -euo pipefail
          python3 scripts/validate-ttl.py
```

### What I learned building this

The biggest surprise was that “token refresh” bugs can hide inside configuration values like `ttl=0`. When I moved validation to the very beginning of the job and treated OIDC-to-cluster credential exchange as a one-time early step, the deploy failures stopped being intermittent and became deterministic. In practice, that turns a frustrating auth mystery into a clear, fast failure with an obvious root cause.

Infrastructure & Scale Posts

A Deterministic Ci/Cd Gate For Aws Codebuild That Blocks “Heisenbugs” Via Content-Addressed Docker Layers

Deterministic Ephemeral Review Apps By Git Commit Digest In Kubernetes

Hardening A Github Actions Oidc Token Refresh Pipeline For Kubernetes With Ttl=0