Skip to content

Automating Enrollment in CI/CD

This document describes how to automate the enrollment and usage of cryptographic keys within a Continuous Integration / Continuous Deployment (CI/CD) pipeline using the Anka Secure API. By integrating key management and cryptographic operations into CI/CD, you can securely manage credentials, automatically rotate keys, and enforce compliance without manual intervention.


Use Case Overview

  1. Pipeline Requests Access

    • The CI/CD pipeline authenticates against the Anka Secure API using application credentials or a bearer token.
  2. Key Generation / Retrieval

    • If needed, the pipeline automatically generates new cryptographic keys (e.g., ephemeral keys for signing or encryption).
    • Alternatively, it retrieves existing keys by kid to ensure a consistent environment across builds.
  3. Perform Cryptographic Operations

    • During build/test stages, the pipeline signs or encrypts artifacts (e.g., container images, binaries).
    • The pipeline may also verify signatures or decrypt data for secure usage within ephemeral environments.
  4. Key Rotation / Revocation

    • On each release cycle (or periodically), the pipeline can rotate or revoke keys to maintain best practices and meet compliance requirements.
    • Old keys can remain valid for verifying existing artifacts, while newly generated keys handle future releases.
  5. Deployment and Logging

    • Once artifacts are signed/encrypted, the pipeline pushes them to a production environment.
    • All cryptographic actions are audited via the Anka Secure API logs, ensuring traceability and compliance reporting.

Typical CI/CD Workflow

Below is a high-level Mermaid diagram showing how a CI/CD pipeline can integrate with the Anka Secure API:

flowchart LR
    A[CI/CD Pipeline] -->|App Auth| B[Anka Secure API]
    B --> C[Key Management]
    B --> D[Crypto Operations]
    C --> B
    D --> B

    subgraph Steps
    E[Generate/Retrieve Key] --> F[Sign/Encrypt Artifacts]
    F --> G[Verify/Deploy Artifacts]
    G --> H[Rotate/Revoke Keys - Periodic]
    end

    A --> E
    E --> F
    F --> G
    G --> H
  1. The CI/CD Pipeline authenticates with the Anka Secure API (e.g., POST /api/authenticate/app).

  2. It requests key generation (or retrieves an existing key) via Key Management endpoints.

  3. The pipeline signs or encrypts artifacts (Docker images, binaries, config files) using Crypto Operations.

  4. The pipeline verifies or deploys these artifacts.

  5. Optionally, it rotates or revokes old keys after a release cycle or at a scheduled interval.


Steps in Detail

1. Authenticate in the Pipeline

  • Endpoint: POST /api/authenticate/app
  • Request (JSON):

{
    "clientId": "myCiCdApp",
    "clientSecret": "myCiCdSecret"
}
- Response (JSON):

{
    "token": "JWT_ACCESS_TOKEN",
    "refreshToken": "JWT_REFRESH_TOKEN"
}
- Store the token in a secure environment variable for subsequent key management and crypto calls.


2. Generate or Retrieve Keys

Depending on your needs, you can create a new key or fetch an existing one:

2.1 Generate a New Key

  • Endpoint: POST /api/key-management/keys
  • Request (JSON):

{
    "kid": "ciCdSigningKey",
    "kty": "RSA",
    "alg": "RSA-2048",
    "keyOps": ["sign","verify"],
    "exportable": false
}
- Response: - 201 Created on successful key generation.

2.2 Retrieve an Existing Key

  • Endpoint: GET /api/key-management/keys/{kid}
  • Example:

GET /api/key-management/keys/ciCdSigningKey
Authorization: Bearer <TOKEN>
- Response: JSON metadata about the key (public portion only if asymmetric).


3. Sign/Encrypt Artifacts

Within the build stage, the pipeline signs or encrypts the generated artifacts so they can be safely deployed.

Example: Signing via Non-Streaming Endpoint

  • Endpoint: POST /api/crypto/sign
  • Request:

{
    "kid": "ciCdSigningKey",
    "data": "Base64_of_Artifact"
}
- Response:

{
    "signature": "Base64Signature",
    "errorMessage": ""
}
Alternatively, if dealing with large artifacts (e.g., multi-GB container images), use streaming endpoints like POST /api/crypto/stream/sign.


4. Verification & Deployment

Once the artifacts have been signed or encrypted, the pipeline can:

  • Verify signatures for integrity checks during staging or QA.
  • Deploy the final artifacts to production, ensuring they are cryptographically protected.

Verification example (non-streaming):

POST /api/crypto/verify
{
  "kid": "ciCdSigningKey",
  "data": "Base64_of_Artifact",
  "signature": "Base64Signature"
}

5. Key Rotation / Revocation

To uphold strong security, the pipeline can periodically rotate keys:

  • Endpoint: POST /api/key-management/keys
    • Generate a new key (e.g., ciCdSigningKey_v2) with the same usage (sign, verify).
  • Revoke the old key:

POST /api/key-management/keys/{kid}/revoke

  • Mark it as REVOKED so it can no longer sign new artifacts. It can still verify older artifacts if needed (if the system is configured to allow partial verification with old keys).

Example CI/CD Script Snippets

Below is a hypothetical snippet for GitLab CI (YAML) that outlines how it might integrate with the Anka Secure API:

stages:
  - auth
  - build
  - sign
  - deploy

variables:
  ANKATECH_API: "https://demo.ankatech.co"
  ANKA_APP_ID: $MY_APP_ID
  ANKA_APP_SECRET: $MY_APP_SECRET
  ANKA_TOKEN: ""

authenticate:
  stage: auth
  script:
    - echo "Authenticating with Anka Secure API..."
    - export ANKA_TOKEN=$(curl -s -X POST "$ANKATECH_API/api/authenticate/app"\
        -H "Content-Type: application/json"\
        -d '{"clientId":"'$ANKA_APP_ID'","clientSecret":"'$ANKA_APP_SECRET'"}' | jq -r '.token')

build:
  stage: build
  script:
    - echo "Building artifact..."
    - ./build-my-app.sh

sign:
  stage: sign
  script:
    - echo "Signing artifact with Anka Secure API..."
    - ARTIFACT_BASE64=$(base64 < ./myArtifact.bin)
    - SIGN_RESPONSE=$(curl -s -X POST "$ANKATECH_API/api/crypto/sign"\
        -H "Authorization: Bearer $ANKA_TOKEN"\
        -H "Content-Type: application/json"\
        -d '{"kid":"ciCdSigningKey","data":"'$ARTIFACT_BASE64'"}')
    - SIGNATURE=$(echo $SIGN_RESPONSE | jq -r '.signature')
    - echo "Signature: $SIGNATURE"

deploy:
  stage: deploy
  script:
    - echo "Deploying artifact + signature..."
    - ./deploy.sh --artifact ./myArtifact.bin --signature "$SIGNATURE"`

Security Considerations

  • Secret Management: Store clientSecret, tokens, and any other credentials in CI/CD secure variables rather than in plain text.
  • Minimal Permissions: Use role-based access control (RBAC) where possible. The CI/CD system should only have the permission it needs (e.g., to generate or sign keys).
  • Network Security: Always use HTTPS/TLS to connect to the Anka Secure API.
  • Key Rotation: Regularly rotate keys to reduce the risk of compromise. Automate this process as part of your pipeline schedule.

Conclusion

By automating enrollment in the Anka Secure API within a CI/CD environment, you gain:

  • Frictionless Key Management: Generate, import, rotate, and revoke keys directly from the pipeline.
  • Secure Code Signing & Encryption: All releases can be cryptographically protected in an auditable, consistent manner.
  • Compliance & Auditing: All operations are logged, ensuring traceability and meeting corporate or regulatory standards.

This integration not only streamlines secure build-and-deploy pipelines but also enhances the overall security posture by unifying cryptographic workflows under a robust, centralized solution.