CI/CD Authentication

Teabar uses OIDC (OpenID Connect) for all authentication, including CI/CD pipelines. Instead of Teabar-managed API keys, you’ll use Keycloak service accounts for programmatic access.

Overview

For CI/CD pipelines and automation, use Keycloak service accounts:

• Managed in Keycloak - Centralized identity management
• Standard OAuth 2.0 - Client credentials flow
• Role-based access - Assign appropriate roles in Keycloak
• Audit trail - All authentication logged in Keycloak

Setting Up a Service Account

1. Request a Service Account

Contact your Keycloak administrator to create a service account with:

• Appropriate client roles for Teabar
• Client credentials grant enabled

2. Obtain Credentials

Your Keycloak admin will provide:

• Client ID: e.g., my-ci-service-account
• Client Secret: Store this securely

3. Generate Access Tokens

Use the client credentials flow to get an access token:

TOKEN=$(curl -s -X POST 
  "https://auth.bcp.technology/realms/teabar/protocol/openid-connect/token" 
  -d "client_id=my-ci-service-account" 
  -d "client_secret=$CLIENT_SECRET" 
  -d "grant_type=client_credentials" | jq -r '.access_token')

export TEABAR_TOKEN="$TOKEN"

Using in CI/CD Pipelines

GitHub Actions

name: Deploy Environment

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - name: Get Keycloak Token
        id: auth
        run: |
          TOKEN=$(curl -s -X POST 
            "${{ vars.KEYCLOAK_URL }}/protocol/openid-connect/token" 
            -d "client_id=${{ vars.KEYCLOAK_CLIENT_ID }}" 
            -d "client_secret=${{ secrets.KEYCLOAK_CLIENT_SECRET }}" 
            -d "grant_type=client_credentials" | jq -r '.access_token')
          echo "token=$TOKEN" >> $GITHUB_OUTPUT
      
      - name: Create environment
        env:
          TEABAR_TOKEN: ${{ steps.auth.outputs.token }}
        run: teactl env create --blueprint myapp --name ci-${{ github.run_id }}

GitLab CI

.get_token: &get_token
  - |
    export TEABAR_TOKEN=$(curl -s -X POST 
      "${KEYCLOAK_URL}/protocol/openid-connect/token" 
      -d "client_id=${KEYCLOAK_CLIENT_ID}" 
      -d "client_secret=${KEYCLOAK_CLIENT_SECRET}" 
      -d "grant_type=client_credentials" | jq -r '.access_token')

deploy:
  script:
    - *get_token
    - teactl env create --blueprint myapp --name mr-${CI_MERGE_REQUEST_IID}

Jenkins

pipeline {
    environment {
        KEYCLOAK_CLIENT_SECRET = credentials('keycloak-client-secret')
    }
    
    stages {
        stage('Deploy') {
            steps {
                script {
                    def token = sh(
                        script: '''
                            curl -s -X POST 
                              "${KEYCLOAK_URL}/protocol/openid-connect/token" 
                              -d "client_id=${KEYCLOAK_CLIENT_ID}" 
                              -d "client_secret=${KEYCLOAK_CLIENT_SECRET}" 
                              -d "grant_type=client_credentials" | jq -r '.access_token'
                        ''',
                        returnStdout: true
                    ).trim()
                    
                    withEnv(["TEABAR_TOKEN=${token}"]) {
                        sh 'teactl env create --blueprint myapp --name jenkins-${BUILD_NUMBER}'
                    }
                }
            }
        }
    }
}

Token Refresh

Access tokens from Keycloak are short-lived (typically 5-15 minutes). For long-running pipelines:

1. Refresh before use - Get a new token before each teactl command
2. Use a wrapper script - Automatically refresh tokens

#!/bin/bash
# teactl-wrapper.sh

get_token() {
  curl -s -X POST 
    "${KEYCLOAK_URL}/protocol/openid-connect/token" 
    -d "client_id=${KEYCLOAK_CLIENT_ID}" 
    -d "client_secret=${KEYCLOAK_CLIENT_SECRET}" 
    -d "grant_type=client_credentials" | jq -r '.access_token'
}

export TEABAR_TOKEN=$(get_token)
teactl "$@"

Role Mapping

Service account permissions are configured in Keycloak:

Security Best Practices

1. Least privilege - Request only necessary roles
2. Rotate secrets - Rotate client secrets periodically
3. Secure storage - Use CI/CD platform’s secret management
4. Audit access - Review Keycloak audit logs

Self-Hosted Deployments

For self-hosted Teabar with your own OIDC provider:

# Helm values.yaml
auth:
  oidc:
    issuerURL: "https://your-idp.example.com/realms/teabar"
    cliClientID: "teabar-cli"

Your OIDC provider must support the client credentials grant for service accounts.

Troubleshooting

Token request failed

curl: (7) Failed to connect to auth.bcp.technology

Check network connectivity to Keycloak.

Invalid client credentials

{"error": "unauthorized_client"}

Verify client ID and secret are correct.

Permission denied

The service account may not have the required roles. Contact your Keycloak administrator.

Learn More

• CLI Authentication - Interactive authentication
• Configuration - Full authentication setup