Governance — Approval, Rollback & Deploy Policies

Tại sao Governance Layer Quan Trọng

Continuous Delivery tốt không chỉ là deploy nhanh — mà là deploy có kiểm soát. Governance trong Cloud Deploy bao gồm:

Ai có thể trigger deploy? (IAM roles)
Ai phải approve trước khi lên production? (approval flows)
Khi nào không được deploy? (deploy policies — freeze windows)
Làm gì khi deploy xảy ra sự cố? (rollback mechanics)
Có thể audit lại những gì đã xảy ra không? (notifications, audit trail)

IAM Role Separation — Deployer vs Approver

Cloud Deploy có các predefined roles với phân quyền rõ ràng:

Role	Permissions	Use case
`roles/clouddeploy.operator`	Full management của Cloud Deploy resources	Platform team
`roles/clouddeploy.releaser`	Create releases, trigger rollouts	CI/CD service accounts
`roles/clouddeploy.approver`	Approve/reject rollouts	Senior engineers, SRE on-call
`roles/clouddeploy.viewer`	Read-only access	Auditors, developers

Điều quan trọng về thiết kế: người tạo Release không được là người approve Rollout lên production. Đây là separation of duties cơ bản trong deployment governance.

Service Account Requirements

Cloud Deploy thực thi deployments thông qua Cloud Build, cần service accounts với permissions đúng:

bash

# Service account cho Cloud Deploy execution
gcloud projects add-iam-policy-binding MY_PROJECT \
  --member="serviceAccount:deploy-sa@MY_PROJECT.iam.gserviceaccount.com" \
  --role="roles/clouddeploy.jobRunner"

# Quyền access cluster GKE
gcloud projects add-iam-policy-binding MY_PROJECT \
  --member="serviceAccount:deploy-sa@MY_PROJECT.iam.gserviceaccount.com" \
  --role="roles/container.developer"

# Quyền đọc rendered manifests từ GCS
gcloud projects add-iam-policy-binding MY_PROJECT \
  --member="serviceAccount:deploy-sa@MY_PROJECT.iam.gserviceaccount.com" \
  --role="roles/storage.objectViewer"

Ngoài ra, Cloud Deploy service account (service-PROJECT_NUMBER@gcp-sa-clouddeploy.iam.gserviceaccount.com) cần roles/iam.serviceAccountTokenCreator trên execution service account — vì Cloud Deploy impersonate SA này khi chạy Cloud Build jobs.

Approval Flows — Cơ Chế Bên Trong

Cấu hình Approval Gate

yaml

# Target với approval requirement
apiVersion: deploy.cloud.google.com/v1
kind: Target
metadata:
  name: prod-gke
requireApproval: true
gke:
  cluster: projects/my-project/locations/us-central1/clusters/prod-cluster

Khi requireApproval: true, bất kỳ Rollout nào targeting Target này sẽ được tạo ở trạng thái PENDING_APPROVAL.

Notification Flow qua Pub/Sub

Cloud Deploy tự động publish message lên Pub/Sub khi Rollout cần approval:

json

{
  "data": {
    "message": {
      "type": "type.googleapis.com/google.cloud.deploy.v1.DeployNotificationEvent",
      "rollout": "projects/my-project/locations/us-central1/deliveryPipelines/my-app/releases/v1-2-3/rollouts/rollout-prod-001",
      "release": "projects/my-project/locations/us-central1/deliveryPipelines/my-app/releases/v1-2-3",
      "pipelineUid": "...",
      "type": "APPROVAL_REQUIRED"
    }
  }
}

Topic mặc định: clouddeploy-approvals. Có thể subscribe và route notification đến:

Slack: Cloud Function/Workflow nhận Pub/Sub message → format → post Slack message
PagerDuty: Alert on-call nếu approval cần trong SLA time
Email: Thông báo approver qua email
Custom approval system: Internal ITSM system (ServiceNow, Jira)

python

# Cloud Function example: Pub/Sub → Slack notification
import base64, json
from slack_sdk import WebClient

def notify_approval_needed(event, context):
    data = json.loads(base64.b64decode(event['data']).decode('utf-8'))
    if data['message']['type'] != 'APPROVAL_REQUIRED':
        return
    
    rollout = data['message']['rollout']
    client = WebClient(token=SLACK_TOKEN)
    client.chat_postMessage(
        channel="#deploy-approvals",
        text=f"🚀 Approval needed for production deploy!\nRollout: {rollout}"
    )

Approve/Reject Rollout

Người có roles/clouddeploy.approver có thể approve:

bash

# Approve
gcloud deploy rollouts approve rollout-prod-001 \
  --release=release-v1-2-3 \
  --delivery-pipeline=my-app-pipeline \
  --region=us-central1

# Reject với reason
gcloud deploy rollouts reject rollout-prod-001 \
  --release=release-v1-2-3 \
  --delivery-pipeline=my-app-pipeline \
  --region=us-central1 \
  --reason="Blocked: pending compliance review"

Sau khi approve, Rollout chuyển sang IN_PROGRESS và bắt đầu deploy. Nếu bị reject, Rollout chuyển sang REJECTED — không thể recover, phải tạo promotion mới nếu muốn retry.

Toàn bộ approve/reject actions được ghi vào Cloud Audit Logs với principal của người thực hiện — đây là audit trail quan trọng cho compliance.

Rollback Mechanics

Rollback là gì trong Cloud Deploy

"Rollback" trong Cloud Deploy không phải là "undo" — nó là tạo một Rollout mới targeting cùng Target nhưng dùng Release cũ (Release của lần deploy thành công gần nhất).

bash

# One-click rollback
gcloud deploy rollouts rollback --to-rollout=rollout-prod-001 \
  --delivery-pipeline=my-app-pipeline \
  --release=release-v1-2-3 \
  --region=us-central1

Điều này tạo rollout mới dùng Release của rollout-prod-001 — tức là revert về version trước đó.

Rollback Process chi tiết

Current state:
  - prod-gke đang chạy release-v1-2-3 (version hiện tại, có vấn đề)
  - release-v1-2-2 là version stable trước đó

Rollback flow:
1. Engineer gọi rollback → chỉ định target rollout để rollback về
2. Cloud Deploy lookup: release của rollout đó là release-v1-2-2
3. Cloud Deploy tạo Rollout mới: rollout-prod-rollback-001
4. Rollout mới dùng rendered manifests của release-v1-2-2 từ GCS
5. Deploy thực hiện bình thường (có thể cần approval nếu target có requireApproval)
6. Cluster quay về state của release-v1-2-2

Điểm quan trọng về approval trong rollback: Theo mặc định, rollback Rollout cũng cần approval nếu Target có requireApproval: true. Trong incident, điều này có thể gây chậm trễ.

Giải pháp: Deploy Policy với rollback action exception, hoặc approver on-call sẵn sàng 24/7 để approve nhanh.

Automatic Rollback qua Repair Automation

Đã được đề cập trong file 04, nhưng đáng nhắc lại: rollback repair automation giúp rollback tự động khi rollout fail, không cần human intervention:

yaml

rules:
- name: auto-rollback
  repairRolloutRule:
    id: rollback-on-failure
    jobs:
    - deploy
    - verify
    repairPhases:
    - rollback:
        destinationPhase: stable

Deploy Policies — Time và Action Restrictions

Deploy Policies là mechanism để ngăn actions deploy trong các conditions cụ thể. Chúng được enforced trước khi IAM check — nếu policy block một action, IAM permissions không relevant.

Theo tài liệu Cloud Deploy: "Cloud Deploy evaluates the action being taken to see if this rule is applicable. That is, does the action type and invoker match the policy? If there's an applicable policy, Cloud Deploy evaluates the action being taken to see if this rule would block the action."

Time-Based Deploy Policies

Freeze windows (non-repeating):

yaml

apiVersion: deploy.cloud.google.com/v1
kind: DeployPolicy
metadata:
  name: year-end-freeze
  region: us-central1
description: "Năm mới freeze — không deploy từ 22/12 đến 2/1"
selectors:
- pipeline:
    id: my-app-pipeline
  target:
    id: prod-gke
rules:
- id: year-end-freeze-rule
  restrictRollouts:
    timeWindows:
      timeZone: Asia/Ho_Chi_Minh
      oneTimeWindows:
      - start: "2024-12-22 17:00"
        end:   "2025-01-02 09:00"

Recurring weekend freeze:

yaml

rules:
- id: weekend-freeze
  restrictRollouts:
    timeWindows:
      timeZone: Asia/Ho_Chi_Minh
      weeklyWindows:
      - daysOfWeek: [FRIDAY]
        startTime: "17:00"
        endTime:   "24:00"
      - daysOfWeek: [SATURDAY, SUNDAY]
        startTime: "00:00"
        endTime:   "24:00"
      - daysOfWeek: [MONDAY]
        startTime: "00:00"
        endTime:   "09:00"

Khi policy active, bất kỳ attempt nào tạo Rollout lên prod-gke sẽ bị reject với:

Policy violation: Deploy policy 'year-end-freeze' blocks this action during freeze window.

Action-Based Deploy Policies

Restrict specific actions (không chỉ time-based):

yaml

rules:
- id: no-direct-prod-rollout
  restrictRollouts:
    invokers:
    - USER         # Block trực tiếp từ user (chỉ cho phép automation)
    actions:
    - CREATE       # Không cho create Rollout trực tiếp
    - APPROVE      # Không cho self-approve

Kết hợp: policy block CREATE bởi USER → chỉ có automation mới được create Rollout lên prod. Mọi human deploy phải qua automation flow với approval.

Policy Selectors

Policy có thể target:

yaml

selectors:
# Target cụ thể
- pipeline:
    id: my-app-pipeline
  target:
    id: prod-gke

# Tất cả targets trong pipeline
- pipeline:
    id: my-app-pipeline

# Target theo labels
- target:
    labels:
      environment: production

Label-based selectors cho phép một policy cover tất cả production targets mà không cần list explicit.

Giới hạn: Tối đa 1,000 policies per project/location. Mỗi policy yêu cầu ít nhất một selector và một rule.

Notifications — Pub/Sub Event System

Cloud Deploy publish events cho mọi significant action lên Pub/Sub topics:

Topic	Events
`clouddeploy-resources`	Create/update/delete pipeline, target, release
`clouddeploy-operations`	Rollout status changes
`clouddeploy-approvals`	Approval required, approved, rejected

Event types trong clouddeploy-operations:

RELEASE_RENDER_IN_PROGRESS
RELEASE_RENDER_SUCCEEDED  
RELEASE_RENDER_FAILED
ROLLOUT_IN_PROGRESS
ROLLOUT_SUCCEEDED
ROLLOUT_FAILED
ROLLOUT_CANCELLED
PHASE_IN_PROGRESS
PHASE_SUCCEEDED
PHASE_FAILED
JOB_IN_PROGRESS
JOB_SUCCEEDED
JOB_FAILED

Granularity này cho phép build monitoring và alerting rất chi tiết. Ví dụ: alert khi bất kỳ ROLLOUT_FAILED nào xảy ra trên production target → PagerDuty alert → on-call investigation.

Audit Trail qua Cloud Audit Logs

Ngoài Pub/Sub, mọi Cloud Deploy action đều được ghi vào Cloud Audit Logs:

json

{
  "protoPayload": {
    "methodName": "google.cloud.deploy.v1.CloudDeploy.ApproveRollout",
    "authenticationInfo": {
      "principalEmail": "senior-engineer@company.com"
    },
    "resourceName": "projects/my-project/locations/us-central1/deliveryPipelines/my-app/releases/v1-2-3/rollouts/rollout-prod-001",
    "request": {
      "approved": true,
      "comment": "Reviewed and approved for production deploy"
    }
  }
}

Audit log đầy đủ: ai tạo Release, ai trigger promotion, ai approve, khi nào deploy succeed/fail. Đây là compliance requirement cho nhiều regulated industries.

Thiết Kế Governance Model cho Production

Pattern: Four-Eyes Deployment

Deployment lên production yêu cầu ít nhất 2 người — người tạo Release (CI/CD) và người approve Rollout (separate human approver):

CI/CD SA (roles/clouddeploy.releaser):
  → Tạo Release → Trigger rollout dev → promote staging → create pending rollout prod

Senior Engineer (roles/clouddeploy.approver):
  → Nhận notification → Review diff → Approve production rollout

Pattern: Automated Staging với Manual Production Gate

Code merge → CI build image → Cloud Deploy Release
  → Auto-rollout dev (no approval)
  → Automation promote → staging rollout (no approval)
  → Automation promote → PENDING_APPROVAL trên prod
  → Alert on-call engineer → Manual review → Approve
  → Production deploy

Pattern: Deploy Policy + Automation cho Scheduled Deploys

Automation: scheduled promote sang prod lúc 2:00 AM (low-traffic window)
Deploy Policy: block manual deploys on weekends
Combined effect:
  - Weekday: developers có thể deploy sau approval
  - Weekends: chỉ có scheduled automation chạy được
  - Year-end freeze: không ai deploy được kể cả automation (nếu automation cũng bị block)

Governance — Approval, Rollback & Deploy Policies ​

Tại sao Governance Layer Quan Trọng ​

IAM Role Separation — Deployer vs Approver ​

Service Account Requirements ​

Approval Flows — Cơ Chế Bên Trong ​

Cấu hình Approval Gate ​

Notification Flow qua Pub/Sub ​

Approve/Reject Rollout ​

Rollback Mechanics ​

Rollback là gì trong Cloud Deploy ​

Rollback Process chi tiết ​

Automatic Rollback qua Repair Automation ​

Deploy Policies — Time và Action Restrictions ​

Time-Based Deploy Policies ​

Action-Based Deploy Policies ​

Policy Selectors ​

Notifications — Pub/Sub Event System ​

Audit Trail qua Cloud Audit Logs ​

Thiết Kế Governance Model cho Production ​

Pattern: Four-Eyes Deployment ​

Pattern: Automated Staging với Manual Production Gate ​

Pattern: Deploy Policy + Automation cho Scheduled Deploys ​

Official References ​

Governance — Approval, Rollback & Deploy Policies

Tại sao Governance Layer Quan Trọng

IAM Role Separation — Deployer vs Approver

Service Account Requirements

Approval Flows — Cơ Chế Bên Trong

Cấu hình Approval Gate

Notification Flow qua Pub/Sub

Approve/Reject Rollout

Rollback Mechanics

Rollback là gì trong Cloud Deploy

Rollback Process chi tiết

Automatic Rollback qua Repair Automation

Deploy Policies — Time và Action Restrictions

Time-Based Deploy Policies

Action-Based Deploy Policies

Policy Selectors

Notifications — Pub/Sub Event System

Audit Trail qua Cloud Audit Logs

Thiết Kế Governance Model cho Production

Pattern: Four-Eyes Deployment

Pattern: Automated Staging với Manual Production Gate

Pattern: Deploy Policy + Automation cho Scheduled Deploys

Official References