Skip to content

Access Levels & Context-Aware Access trong VPC SC

Vấn đề cần giải quyết

Service perimeter theo mặc định block tất cả request từ bên ngoài. Nhưng thực tế, không phải mọi request "bên ngoài" đều là nguy hiểm — kỹ sư từ mạng nội bộ công ty cần được truy cập, service accounts từ các project partner cần được cho phép, admin từ thiết bị được quản lý cần có exception.

Access levels là cơ chế để định nghĩa "request nào từ bên ngoài được phép vào perimeter mà không cần viết ingress rule riêng biệt". Chúng là attribute-based conditions — tập hợp các điều kiện về ngữ cảnh của request.

Access levels được quản lý bởi Access Context Manager, một service riêng biệt nhưng được VPC SC sử dụng để evaluate conditions.

Internal Model: Access Context Manager và Access Levels

Kiến trúc Access Context Manager

Access Context Manager (ACM) là service quản lý access policies và access levels. Nó không enforce gì — nó chỉ định nghĩa các điều kiện. Enforcement được thực hiện bởi VPC SC (và các Google services khác như Identity-Aware Proxy).

Access Context Manager
└── Access Policy (accessPolicies/POLICY_ID)
    ├── Access Level: "corp-network"
    │   └── Conditions: IP in 203.0.113.0/24 (công ty A)
    │                   IP in 198.51.100.0/24 (công ty B)

    ├── Access Level: "trusted-device"
    │   └── Conditions: Device compliant = true
    │                   OS = Chrome OS

    └── Access Level: "corp-and-device"  (combined)
        └── Combination: "corp-network" AND "trusted-device"

Một access level có thể được reference bởi nhiều service perimeters khác nhau. Khi cập nhật một access level, mọi perimeter reference đến nó đều tự động nhận được cập nhật.

Cách VPC SC sử dụng access levels

Khi một request đến từ bên ngoài perimeter, VPC SC evaluates xem request đó có match bất kỳ access level nào được attach vào perimeter không:

Request từ IP 203.0.113.50

    ├── VPC SC kiểm tra: IP này match access level nào?
    │       └── "corp-network" có condition: 203.0.113.0/24
    │               └── 203.0.113.50 ∈ 203.0.113.0/24 → MATCH

    └── Access level match → Request được allow vào perimeter

Access levels khi attach vào perimeter hoạt động như một "whitelist" cho phép inbound request — không cần viết ingress rule riêng cho mỗi trường hợp.

Basic Access Levels

Basic access levels được xây dựng từ các điều kiện cơ bản có thể kết hợp với nhau.

IP Address Conditions

Điều kiện phổ biến nhất — cho phép truy cập từ các dải IP cụ thể:

yaml
# Basic access level: corporate networks
name: accessPolicies/123456/accessLevels/corp_networks
basic:
  conditions:
    - ipSubnetworks:
        - 203.0.113.0/24      # Corporate office A
        - 198.51.100.0/24     # Corporate office B
        - 10.100.0.0/16       # VPN range

Quan trọng: Chỉ được dùng public IP ranges trong IP-based access levels. Private IP ranges (RFC 1918: 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) không được hỗ trợ trong basic access level IP conditions — vì trong môi trường cloud, private IPs có thể được reuse và không uniquely identify một network.

Để cho phép access từ VPC networks (private IPs), cần dùng ingress rules với vpcNetworkSources hoặc access levels mới hỗ trợ private IP access.

Geographic Region Conditions

Cho phép hoặc block access dựa trên vị trí địa lý (quốc gia) của client IP:

yaml
basic:
  conditions:
    - regions:
        - VN   # Vietnam
        - SG   # Singapore
        - US   # United States

Geographic conditions dùng GeoIP database của Google để xác định vị trí của IP. Không phải 100% chính xác, đặc biệt với VPN traffic. Thường dùng để block access từ các quốc gia có risk cao, không nên dùng để enforce strict access cho các quốc gia cụ thể.

Device Policy Conditions

Yêu cầu thiết bị của client phải đáp ứng các tiêu chí bảo mật nhất định. Tính năng này yêu cầu Chrome Enterprise Premium (trước đây là BeyondCorp Enterprise):

yaml
basic:
  conditions:
    - devicePolicy:
        requireScreenlock: true
        allowedEncryptionStatuses:
          - ENCRYPTED
        osConstraints:
          - osType: DESKTOP_CHROME_OS
            minimumVersion: "91.0"
        requireAdminApproval: true
        requireCorpOwned: true

Device policy conditions sử dụng thông tin từ Endpoint Verification — một Chrome extension hoặc agent thu thập device attributes và báo cáo cho Google's Context-Aware Access system.

Principal (Identity) Conditions

Giới hạn access level chỉ áp dụng cho một tập danh tính cụ thể:

yaml
basic:
  conditions:
    - members:
        - user:admin@company.com
        - serviceAccount:billing-sa@project.iam.gserviceaccount.com
        - group:sre-team@company.com

Khi kết hợp với IP conditions trong cùng một access level, logic là AND: request phải match tất cả conditions trong cùng một condition block.

Combining Conditions: AND vs OR

Trong một basic access level, các conditions kết hợp theo hai cách:

yaml
basic:
  # Tất cả conditions trong cùng một item → AND
  conditions:
    - ipSubnetworks: [203.0.113.0/24]   # AND
      devicePolicy:
        requireScreenlock: true          # AND này với IP condition
    # Item thứ hai → OR với item đầu
    - members: [user:admin@company.com]
  
  # combiningFunction mặc định là OR giữa các condition items
  combiningFunction: OR

Với combiningFunction: AND, request phải match tất cả condition items. Với OR (default), request chỉ cần match ít nhất một condition item.

Custom Access Levels với CEL

Khi nào dùng custom access level?

Basic access levels đủ cho hầu hết use cases, nhưng có một số trường hợp cần logic phức tạp hơn:

  • Điều kiện dựa trên header của request
  • Logic kết hợp nhiều attributes với AND/OR phức tạp
  • Kiểm tra các attributes mà basic conditions không hỗ trợ
  • Conditional logic dựa trên giá trị của credential

Cú pháp custom access level

Custom access levels viết bằng một subset của Common Expression Language (CEL). Các expression evaluator của Access Context Manager hỗ trợ các attributes sau:

request.auth              - Thông tin authentication
origin.ip                 - IP address của client
origin.region_code        - Country code (ISO 3166-1)
device.is_corp_owned      - Thiết bị thuộc sở hữu công ty?
device.screen_lock_secured - Có screen lock không?
device.encryption_status  - Trạng thái mã hóa
device.os_type            - Loại OS
device.os_version         - Phiên bản OS

Ví dụ custom access level cho phép admin từ corp network hoặc từ bất kỳ đâu nhưng phải dùng thiết bị được mã hóa:

# Custom CEL expression
(origin.ip.inIpRange("203.0.113.0/24") ||
 origin.ip.inIpRange("198.51.100.0/24")) ||
(device.encryption_status == "ENCRYPTED" &&
 device.is_corp_owned == true)

Giới hạn của custom access levels

Custom access levels có một số ràng buộc quan trọng:

Không thể dùng thông tin bên ngoài request: CEL expression chỉ có thể access các attributes được cung cấp bởi Access Context Manager — không thể gọi external APIs hay query databases.

Không thể combine custom với basic trong cùng access level: Một access level là hoặc basic hoặc custom, không thể kết hợp.

Chỉ hỗ trợ qua gcloud CLI hoặc API: Custom access levels với identity-based allowlists không thể tạo qua Google Cloud Console.

Private IP Access Levels — Tính Năng Mới

Trước đây, access levels chỉ hỗ trợ public IP. Từ 2024, VPC SC hỗ trợ private IP address ranges trong access levels:

yaml
basic:
  conditions:
    - vpcNetworkSources:
        - vpcSubnetwork:
            network: projects/my-project/global/networks/my-vpc
            vpcIpSubnetworks:
              - 10.0.1.0/24    # Private IP range trong VPC

Đây cho phép định nghĩa access level dựa trên nguồn gốc VPC network và private IP subnet, không chỉ public IP. Khi combine với ingress rules, pattern này cho phép fine-grained control: "Chỉ VMs trong subnet 10.0.1.0/24 của VPC này mới được truy cập resources trong perimeter."

Ví Dụ: Access Level Hierarchy Thực Tế

Một tổ chức thường cần nhiều access levels cho các use cases khác nhau:

Access Policy
├── Level: "corporate-strict"
│   Điều kiện: IP corp AND device compliant
│   Dùng cho: Perimeter chứa production data

├── Level: "corporate-relaxed"  
│   Điều kiện: IP corp (bất kỳ device)
│   Dùng cho: Perimeter development/staging

├── Level: "admin-emergency"
│   Điều kiện: User là super-admin
│   Dùng cho: Break-glass access khi corp network down

└── Level: "partner-api"
    Điều kiện: IP của partner company
    Dùng cho: Cho phép partner's service access một số APIs

Quan trọng: mỗi service perimeter có thể attach nhiều access levels — và một request chỉ cần match một trong số đó là được phép (OR semantics giữa các access levels).

Sai Lầm Phổ Biến

Dùng private IP trong basic access level: Basic IP conditions không support private IP ranges. Nếu team của bạn muốn allow access từ IP 10.0.0.0/8, bạn cần dùng ingress rules với vpcNetworkSources, không phải basic access level.

Quên xem xét service account access: Access levels áp dụng cho human users rất tốt, nhưng service accounts thường cần được handle qua ingress rules dựa trên project/identity, không phải access level — vì service accounts không có "device" hay "IP từ corp network".

Quá phụ thuộc vào geographic conditions: GeoIP không chính xác 100%. Nếu dùng region conditions để block một quốc gia, hãy coi đây là "best effort" không phải "absolute block".

Không test access level trước khi attach vào enforced perimeter: Luôn dùng dry-run mode (xem Chapter 04) để validate access level behavior trước khi apply lên enforced perimeter.

References