GitHub API Access

This guide shows how to store a GitHub Personal Access Token in a Kubernetes Secret and have Riptides inject it transparently into outbound requests to api.github.com — including calls made by the gh CLI — with no token management in the workload.

Overview

Accessing the GitHub API or running gh CLI commands from a workload traditionally requires embedding a token in environment variables, mounted files, or application configuration. With Riptides, you can instead:

Store your GitHub PAT in a Kubernetes Secret.
Create a WorkloadIdentity that assigns a SPIFFE identity to the workload and enables TLS intercept for outbound connections.
Create a CredentialSource that references the Secret.
Create a CredentialBinding that tells the kernel to inject Authorization: Bearer <token> into outbound connections to api.github.com.

Your application code and gh CLI invocations make plain, unauthenticated requests. The Riptides kernel module intercepts each outbound connection to api.github.com, terminates TLS, injects the credential, and re-originates the connection to GitHub.

Prerequisites

A running Riptides control plane with minimum one daemon deployed
kubectl access to the riptides-system namespace
The oidc-login kubectl plugin (kubelogin) for control plane authentication. See Install the oidc-login Plugin.
A GitHub Personal Access Token with the scopes your workload requires (e.g., repo, read:org)
gh the GitHub CLI

Step 1: Create a Kubernetes Secret

Store your GitHub PAT in a Kubernetes Secret in the riptides-system namespace.

kubectl create secret generic github-pat \
  --from-literal=token='<your-github-pat>' \
  -n riptides-system

Security note: The Secret lives in the riptides-system namespace. Access is mediated through CredentialSource and CredentialBinding resources — the workload never directly accesses the Secret.

Step 2: Create a WorkloadIdentity

The WorkloadIdentity must exist before other resources that reference its workloadID. It assigns a SPIFFE identity to the workload and enables TLS intercept for outbound connections so the kernel can inject credentials.

First, find the daemon running on the host:

riptides-cli ctl get daemons

Retrieve its ID:

riptides-cli ctl get daemon <daemon-name> -o jsonpath='{.spec.workloadID}'

Use that value in the scope.daemon.id field below:

riptides-cli ctl apply -f - <<EOF
apiVersion: core.riptides.io/v1alpha1
kind: WorkloadIdentity
metadata:
  name: gh-cli
  namespace: riptides-system
spec:
  connection:
    tls:
      mode: PERMISSIVE
      intercept: true
  scope:
    daemon:
      id: "<daemon-id>"
  selectors:
    - process:name: gh
  workloadID: "gh-cli"
EOF

Key field:

connection.tls.intercept: true: The kernel intercepts outbound TLS connections and handles credential injection. Required for the injection propagation mode to work.

Step 3: Create a CredentialSource

The CredentialSource tells Riptides where to find the credential and how to treat it.

riptides-cli ctl apply -f - <<EOF
apiVersion: core.riptides.io/v1alpha1
kind: CredentialSource
metadata:
  name: github-token-source
  namespace: riptides-system
spec:
  kubernetes:
    secretRef:
      name: github-pat
      key: token
    type: BearerToken
EOF

Verify:

riptides-cli ctl get credentialsource github-token-source
# STATE should show AVAILABLE

Step 4: Create a Service for the GitHub API

Define a Riptides Service for api.github.com. This tells Riptides which outbound destinations should receive the credential.

riptides-cli ctl apply -f - <<EOF
apiVersion: core.riptides.io/v1alpha1
kind: Service
metadata:
  name: github-api-svc
  namespace: riptides-system
spec:
  addresses:
    - address: api.github.com
      port: 443
  external: true
  labels:
    api: github
EOF

Step 5: Create a CredentialBinding

The CredentialBinding connects the CredentialSource to your workload and configures how the credential is delivered.

riptides-cli ctl apply -f - <<EOF
apiVersion: core.riptides.io/v1alpha1
kind: CredentialBinding
metadata:
  name: github-token-binding
  namespace: riptides-system
spec:
  credentialSource: github-token-source
  propagation:
    injection:
      selectors:
        - api: github
  workloadID: "gh-cli"
EOF

Verify:

riptides-cli ctl describe credentialbinding github-token-binding
# STATE should show OK

When the workload makes an outbound HTTPS request to api.github.com, the kernel intercepts the connection and injects Authorization: Bearer <token>. The workload does not set any authentication headers.

Step 6: Configure the Riptides CA Bundle

Because tls.intercept: true causes the kernel to terminate and re-originate TLS, processes need to trust the Riptides CA. The daemon automatically merges the intercept CA into the OS trust store, so on most hosts no extra configuration is needed.

In containers or environments where the OS trust store is not updated by the daemon, you will need to point your runtime at the Riptides CA file. gh is written in Go and uses the OS trust store — in containers, SSL_CERT_FILE covers it alongside other Go-based tools.

See Trusting the Riptides CA for the full list of runtime-specific environment variables.

Step 7: Use the Credential

Your workload makes plain, unauthenticated requests — no token handling in the application or script. The kernel intercepts each connection to api.github.com and injects the credential automatically.

`gh` CLI

gh requires GH_TOKEN to be set to a non-empty value before it will make API requests. Export a placeholder so gh proceeds — Riptides replaces it on the wire:

export GH_TOKEN=.

Then make API calls as normal:

gh api gists

The kernel intercepts gh’s outbound connection to api.github.com, strips the placeholder, injects the real PAT, and re-originates the TLS session to GitHub. The gh process never sees the token.

HTTP libraries and curl

import requests

# No Authorization header — the Riptides kernel module injects it
response = requests.get("https://api.github.com/user/repos")
print(response.json())

# No -H flags needed
curl https://api.github.com/user