Освоение операций KCC с помощью Google Antigravity

1. Введение

В этом практическом занятии вы узнаете о Google Antigravity (далее в документе именуемом просто Antigravity), платформе для разработки с использованием агентов, которая переводит IDE в эпоху разработки, ориентированной на агентов.

В отличие от стандартных помощников по программированию, которые просто автоматически дополняют строки, Antigravity предоставляет «Центр управления» для управления автономными агентами, которые могут планировать, программировать и даже просматривать веб-страницы, чтобы помочь вам в разработке.

Antigravity разработана как платформа, ориентированная на агентов. Она предполагает, что ИИ — это не просто инструмент для написания кода, а автономный субъект, способный планировать, выполнять, проверять и итеративно решать сложные инженерные задачи с минимальным участием человека.

Что вы узнаете

  • Установка и настройка Antigravity.
  • Изучение ключевых концепций антигравитации, таких как менеджер агентов, редактор, браузер и многое другое.
  • Создание с нуля готового к использованию инструмента KCC Ops для управления ресурсами Google Cloud с обеспечением безопасности и соответствия нормативным требованиям.

Что вам понадобится

В настоящее время Antigravity доступен в режиме предварительного просмотра для личных учетных записей Gmail. Он предоставляет бесплатную квоту для использования премиум-моделей.

Программа Antigravity должна быть установлена ​​локально на вашем компьютере. Продукт доступен для Mac, Windows и некоторых дистрибутивов Linux. Помимо вашего компьютера, вам потребуется следующее:

  • Аккаунт Gmail (личный аккаунт Gmail).
  • Аккаунт Google Cloud и проект Google Cloud
  • Веб-браузер, такой как Chrome , поддерживающий консоль Google Cloud и Cloud Shell.

2. Настройка и требования

Настройка проекта

Создайте проект в Google Cloud.

  1. В консоли Google Cloud на странице выбора проекта выберите или создайте проект Google Cloud .
  2. Убедитесь, что для вашего облачного проекта включена функция выставления счетов. Узнайте, как проверить, включена ли функция выставления счетов для проекта .

Этот практический семинар предназначен для пользователей и разработчиков всех уровней (включая начинающих).

3. Установка

Если у вас ещё не установлена ​​Antigravity, давайте начнём с её установки. В настоящее время продукт доступен для предварительного просмотра, и вы можете начать работу с ним, используя свою личную учётную запись Gmail.

Перейдите на страницу загрузок и выберите подходящую версию операционной системы для вашего случая. Запустите установщик приложения и установите его на свой компьютер. После завершения установки запустите приложение Antigravity.

Основные этапы настройки:

  • Выберите порядок настройки: Мы рекомендуем начать работу с чистого листа для этого практического занятия.
  • Разработка, основанная на отзывах (рекомендуется) : выберите этот вариант. Он позволяет агенту принимать решение и возвращать его пользователю для утверждения, что крайне важно для работы инфраструктуры.

Далее настройте редактор и войдите в свою учетную запись Google. Наконец, примите Условия использования .

4. Настройка инфраструктуры: GKE и Config Connector

Прежде чем создавать навык, вам потребуется среда Google Cloud с установленным вручную и настроенным в режиме пространства имен Config Connector (KCC) . Это позволит вам управлять ресурсами GCP как объектами Kubernetes.

Шаг 0: Подготовьте окружающую среду

1. Предварительные требования для участия в кластере

Создайте новый кластер GKE с включенными необходимыми функциями:

# Set your variables
export PROJECT_ID=$(gcloud config get-value project)
export CLUSTER_NAME="kcc-ops-cluster"
export REGION="us-central1"

# Create the cluster
gcloud container clusters create ${CLUSTER_NAME} \
    --region ${REGION} \
    --release-channel "regular" \
    --workload-pool=${PROJECT_ID}.svc.id.goog \
    --logging=SYSTEM \
    --monitoring=SYSTEM

# Get cluster credentials
gcloud container clusters get-credentials ${CLUSTER_NAME} --region ${REGION}

2. Установите оператор Config Connector.

Оператор следит за тем, чтобы ваша установка всегда была в актуальном состоянии.

# Download the latest Config Connector operator
gcloud storage cp gs://configconnector-operator/latest/release-bundle.tar.gz release-bundle.tar.gz

# Extract the bundle
tar zxvf release-bundle.tar.gz

# Install the operator (Standard Cluster)
kubectl apply -f operator-system/configconnector-operator.yaml

3. Настройка режима пространства имен

Создайте ресурс ConfigConnector для указания режима работы.

# configconnector.yaml
apiVersion: core.cnrm.cloud.google.com/v1beta1
kind: ConfigConnector
metadata:
  name: configconnector.core.cnrm.cloud.google.com
spec:
  mode: namespaced
  stateIntoSpec: Absent

kubectl apply -f configconnector.yaml

4. Создайте идентификатор и пространство имен.

Для этой лабораторной работы мы будем использовать пространство имен default и выделенный сервисный аккаунт Google (GSA).

# Set your variables
export PROJECT_ID=$(gcloud config get-value project)
export NAMESPACE="default"

# Create the Google Service Account
gcloud iam service-accounts create kcc-identity --project ${PROJECT_ID}

# Grant permissions on the project
gcloud projects add-iam-policy-binding ${PROJECT_ID} \
    --member="serviceAccount:kcc-identity@${PROJECT_ID}.iam.gserviceaccount.com" \
    --role="roles/owner"

# Grant Metric Writer permissions
gcloud projects add-iam-policy-binding ${PROJECT_ID} \
    --member="serviceAccount:kcc-identity@${PROJECT_ID}.iam.gserviceaccount.com" \
    --role="roles/monitoring.metricWriter"

# Bind GSA to KSA via Workload Identity
gcloud iam service-accounts add-iam-policy-binding \
    kcc-identity@${PROJECT_ID}.iam.gserviceaccount.com \
    --member="serviceAccount:${PROJECT_ID}.svc.id.goog[cnrm-system/cnrm-controller-manager-${NAMESPACE}]" \
    --role="roles/iam.workloadIdentityUser"

5. Настройка пространства имен

Создайте объект ConfigConnectorContext для отслеживания пространства имен.

# configconnectorcontext.yaml
apiVersion: core.cnrm.cloud.google.com/v1beta1
kind: ConfigConnectorContext
metadata:
  name: configconnectorcontext.core.cnrm.cloud.google.com
  namespace: default
spec:
  googleServiceAccount: "kcc-identity@${PROJECT_ID}.iam.gserviceaccount.com"
  stateIntoSpec: Absent

kubectl apply -f configconnectorcontext.yaml

6. Проверьте установку.

Дождитесь готовности контроллера к использованию пространства имен default .

kubectl wait -n cnrm-system \
    --for=condition=Ready pod \
    -l cnrm.cloud.google.com/component=cnrm-controller-manager \
    -l cnrm.cloud.google.com/scoped-namespace=default

5. Менеджер агентов: Центр управления полетами

Antigravity является ответвлением от открытого программного обеспечения Visual Studio Code (VS Code), но радикально меняет пользовательский интерфейс, отдавая приоритет управлению агентами, а не редактированию текста. Интерфейс разделен на два отдельных основных окна: Editor и Agent Manager .

Менеджер агентов

При запуске Antigravity пользователя обычно встречает Менеджер агентов. Этот интерфейс действует как панель управления миссией . Он предназначен для высокоуровневой оркестровки, позволяя разработчикам создавать, отслеживать и взаимодействовать с несколькими агентами, работающими асинхронно в разных рабочих областях или задачах.

В этом представлении разработчик выступает в роли архитектора. Он определяет высокоуровневые цели. Каждый из этих запросов запускает отдельный экземпляр агента. Пользовательский интерфейс предоставляет визуализацию этих параллельных рабочих потоков, отображая статус каждого агента, созданные им артефакты (планы, результаты, различия) и любые ожидающие запроса на утверждение человеком.

6. Антигравитационный браузер и артефакты

В процессе планирования и выполнения своей работы Antigravity создает артефакты . К ним относятся файлы в формате Markdown, архитектурные схемы, изображения, записи браузера и сравнения кода.

Артефакты помогают преодолеть «пробело в доверии».

Когда агент заявляет: «Я исправил ошибку», разработчику предварительно приходилось читать код, чтобы это проверить. В Antigravity агент создает артефакт, чтобы это доказать.

Артефакты

Вот основные артефакты, созданные с помощью антигравитации:

  • Task Lists : структурированный план, составленный перед написанием кода.
  • Implementation Plan : Архитектурные изменения с подробным техническим описанием.
  • Walkthrough : Краткое описание изменений и способов их тестирования.
  • Browser Recordings : Видеозаписи сеансов работы браузера для проверки пользовательского интерфейса.

Антигравитационный браузер

Когда агенту необходимо взаимодействовать с веб-страницами, он вызывает субагента браузера . Этот субагент может щелкать мышью, прокручивать страницу, вводить текст и читать сообщения в консоли. Он использует специализированную модель для работы со страницами, открытыми в браузере, управляемом Antigravity.

7. Опыт работы редактором

Редактор сохраняет привычный интерфейс VS Code. Он включает в себя стандартный файловый менеджер, подсветку синтаксиса и экосистему расширений.

Основные возможности редактора:

  • Автозаполнение : интеллектуальные подсказки принимаются при нажатии клавиши Tab .
  • Вкладка для импорта : предлагает добавить недостающие зависимости.
  • Команды ( Cmd + I ) : Запуск автодополнения с использованием естественного языка.
  • Панель агента ( Cmd + L ) : Переключите панель агента, чтобы задавать вопросы или ссылаться на файлы, используя @ .

8. Предоставление обратной связи

В основе Antigravity лежит способность легко собирать ваши отзывы. Эти артефакты позволяют вам оставлять комментарии агенту в стиле Google Docs .

При добавлении комментария к плану или задаче обязательно отправьте его. Это направит агента в нужное вам русло.

9. Развитие навыков работы в KCC Ops

Теперь, когда вы разобрались с платформой, давайте создадим навык KCC Ops .

Kubernetes Config Connector (KCC) позволяет управлять ресурсами GCP как объектами K8s. Однако он требует наличия механизмов защиты для предотвращения расхождения конфигураций, нарушений соответствия требованиям и случайного повторного создания ресурсов.

Шаг 1: Структурирование навыка

В корневой директории вашей рабочей области создайте структуру каталогов для вашего навыка:

mkdir -p .agents/skills/kcc-ops/scripts
mkdir -p .agents/skills/kcc-ops/resources/policies/templates
mkdir -p .agents/skills/kcc-ops/resources/policies/constraints

Шаг 2: Создайте файл SKILL.md (мозг).

Файл SKILL.md определяет метаданные и основное «золотое правило» для агента. Создайте .agents/skills/kcc-ops/SKILL.md : 

---
name: kcc-ops
description: Assists with Config Connector (KCC) configuration, resource generation, and troubleshooting on Google Cloud.
---

# Config Connector (KCC) Operations Skill

Use this skill to manage Google Cloud resources using Kubernetes-style configuration (Config Connector).

## 🛑 GOLDEN RULE: Separate Generation from Application

**NEVER generate and apply a manifest in a single autonomous step.**

1. **Craft:** Write the generated manifest to a local file.
2. **Analyze:** Present the manifest to the user. Perform Impact Analysis and Dry Runs. Explain the consequences of the change (e.g., "If this topic is deleted, the attached subscription becomes orphaned").
3. **Wait:** Pause execution and explicitly wait for user permission to proceed.
4. **Apply:** Only run `kubectl apply` *after* the user has reviewed the manifest and the impact analysis, and then unequivocally confirmed you should proceed.

## Core Responsibilities

0. **Context Verification**: Verify the execution context (cluster, namespace, GCP project, user account) with the user before performing any operations.
1. **Installation & Health**: Verify KCC is properly installed and healthy on the target cluster.
2. **Resource Inventory**: Query and summarize existing KCC resources within a namespace.
3. **Brownfield Bulk Export (Adoption)**: Export existing GCP project resources into valid KCC YAML manifests.
4. **Manifest Generation**: Generate valid YAML manifests for GCP resources using KCC CRDs.
5. **Impact Analysis**: Identify ancillary services and resources (e.g., Cloud Run, Apps) that depend on a resource being modified.
6. **Change Differentiation**: Generate diff summaries for resource edits to support change control.
7. **Policy Compliance**: Vet KCC manifests against OPA/Gatekeeper policies.
8. **Troubleshooting**: Analyze resource status, and consult the troubleshooting guide to resolve reconciliation issues.

## Guidelines for Operations

### 0. Context Verification

Before performing **any operations or executing commands** (including health checks), you **MUST** verify the current execution context and obtain explicit user confirmation.

1. **Read Context:** Use commands like `kubectl config current-context`, `kubectl config view --minify -o jsonpath='{.contexts[0].context.namespace}'`, `gcloud config get-value project`, and `gcloud config get-value account` to determine the active environment.
2. **Present & Ask:** Show this information to the user clearly (e.g., "I see my context is X, namespace is Y, project is Z, and account is A. Is this correct?").
3. **Wait:** Do not proceed with any other steps or scripts until the user has confirmed or provided corrections.

### 1. Installation & Health Check

Before performing operations, ensure the environment is ready:

- **Automation**: You MUST use `./scripts/check-health.sh` to verify namespaces, controllers, and CRDs. Do not use manual kubectl commands for health checks, as the script enforces standard formatting and context verification.

### 2. Resource Inventory & Discovery

To understand the current state of infrastructure:

- **Automation**: You MUST use `./scripts/inventory.sh` to get a summary table of all KCC resources. Do not use manual kubectl queries, as the script is optimized to securely discover all CRDs with context validation.

### 3. Manifest Structure

- All KCC resources belong to the `cnrm.cloud.google.com` API group.
- Use the `cnrm.cloud.google.com/project-id` annotation for cross-project resource management if not using Namespaced Mode.
- Always include `apiVersion`, `kind`, `metadata`, and `spec`.

### 4. Official Resource Reference (Agent Action)

When generating or troubleshooting manifests, you **must not guess** the API schema. Always consult the [Official Config Connector Reference](https://cloud.google.com/config-connector/docs/reference/overview) for the exact API version, kind, and required fields for the specific resource and cross reference with the official [github repository](https://github.com/GoogleCloudPlatform/k8s-config-connector/tree/master/config/crds/resources).

### 5. Troubleshooting Checklist

When a resource is not reconciling (check `kubectl get <kind> <name> -o yaml`):

- **Ready Condition**: Look for `status.conditions` where `type: Ready` and `status: "False"`.
- **Reason/Message**: Check the `reason` and `message` fields in the status conditions.
- **Consult the Guide**: Immediately check `./resources/troubleshooting-guide.md` for definitions of the error reason (e.g. `DependencyInvalid`, `ManagementConflict`) and follow its resolution steps.
- **Common Issues**:
  - Permissions: The KCC service account lacks IAM roles.
  - Quotas: GCP project quota exceeded.
  - Conflicts: Resource already exists or is managed by another tool.
  - Immutable Fields: Attempting to change a field that requires resource recreation. Look for "Update failed" errors related to immutable fields.
  - Reference Resolution: Check if the resource is waiting for a dependency (e.g., `referenced project not found`).

### 6. Impact Analysis (Ancillary Services)

Before modifying a resource (e.g., GCS Bucket, Pub/Sub Topic), verify whatElse depends on it:

- **Reference Search (Cluster-wide)**: Search for other KCC resources that reference the item.

  ```bash
  # Example: Find resources referencing a bucket named 'my-data-bucket'
  kubectl get-all -n <namespace> -o yaml | grep -C 5 "my-data-bucket"
  ```

- **IAM-based Analysis**: Check for IAM Service Accounts that have roles on the specific resource. A Cloud Run job or GKE Workload Identity might be using those permissions.
- **Common Ancillary Dependencies**:
  - **Storage Buckets**: Look for Cloud Run/GKE mounts (CSI), Cloud Functions triggers, or Dataflow jobs.
  - **Networks**: Check for Firewall rules, Forwarding rules, and GKE cluster assignments.
  - **IAM Policies**: Changing a policy might break access for external applications not managed by KCC.
- **Resource Graph**: Use `gcloud asset search-all-resources` to find resources that might have implicit links.

### 3. Policy Compliance & Best Practices

Evaluate KCC manifests against security and governance policies. The vetting tool supports three source modes:

- **Built-in Mode (Default)**: Uses the skill's high-fidelity `v1beta1` library (300+ Anthos constraints).
  - `Usage: ./scripts/vet-policy.sh <manifest-path>`
- **Remote Mode**: Clones and vets against an external Git repository.
  - `Usage: ./scripts/vet-policy.sh <manifest-path> <repo-url> [git-ref]`
  - ⚠️ **Note**: External libraries like the legacy GCP Policy Library may be out-of-date and cause schema validation errors with modern `gator`.
- **Local Mode**: Vets against a local directory of policies.
  - `Usage: ./scripts/vet-policy.sh <manifest-path> /path/to/local/policies`

**Interaction Model:**

1. Call `./scripts/vet-policy.sh` with the appropriate arguments.
2. Interpret the `=== KCC Best Practices ===` and `=== OPA/Gatekeeper ===` reports.
3. Supplement automated findings with manual review for specific security features not yet covered by OPA (e.g., `publicAccessPrevention: enforced`, `versioning: {enabled: true}`).

  ```bash
  # Run the skill's helper script (repo URL and branch are optional)
  ./scripts/vet-policy.sh manifest.yaml [policy-repo-url] [policy-ref]
  ```

## Skill Assets

This skill includes additional resources to streamline operations:

- **`scripts/`**: Automation scripts (e.g., `vet-policy.sh`, `bulk-export.sh`).
- **`examples/`**: Reference KCC manifests (e.g., `restricted-bucket.yaml`).
- **`resources/`**: Common templates, documentation snippets, and troubleshooting guides (e.g., `troubleshooting-guide.md`).

### 4. Safety Rails for Applying Manifests

Before applying any KCC manifest update to an existing resource, you MUST:

- **Verify Immutable Fields**: Call `./scripts/verify-immutable.sh <manifest-path>` to detect updates to fields (like `location`, `name`, `project-id`) that trigger destructive resource recreation.
- **Explain Impact**: If destructive changes are detected, you MUST warn the user and explain the downtime/data loss implications before requesting approval.

### 5. Emergency Recovery & Troubleshooting

If a resource is stuck in a "Deletion" or "Error" state:

- **Check for Abondon Flag**: Check if the resource has the `cnrm.cloud.google.com/deletion-policy: abandon` annotation. If it does, you will need to remove the annotation and then force delete the resource.
- **Force Delete**: Call `./scripts/force-delete.sh <kind> <name> [namespace]` to bypass Kubernetes finalizers and remove the resource from the cluster.
- **Orphan Warning**: Inform the user that force-deleting a KCC object may leave an orphaned resource in Google Cloud that requires manual cleanup.

### 6. Change Differentiation

When editing an existing resource, always generate a diff to summarize the change for reviewers or Git history:

- **Local Diff**:

  ```bash
  # Diff a local file against the cluster state
  kubectl diff -f modified-resource.yaml
  ```

- **Commit Summary Template**:

  ```text
  [KCC Change] Update <ResourceName> (<Kind>)
  - Field 'spec.foo' changed from 'X' to 'Y'
  - Impact: Ancillary service <ServiceName> will see updated <Config>
  ```

### 9. Best Practices

- **Namespaced Mode**: Prefer namespaced mode for better isolation.
- **Sensitive Data**: Use `spec.credential.secretRef` or similar for sensitive fields.
- **Resource Naming**: Use consistent naming conventions that match your Kubernetes/GCP standards.
- **Annotations**:
  - `cnrm.cloud.google.com/deletion-policy: abandon`: Keep GCP resource on KCC deletion.
  - `cnrm.cloud.google.com/state-into-spec: absent`: Prevents KCC from syncing GCP state back into the Kubernetes object (useful for avoiding reconciliation loops on fields like node counts).

## Common Resource Examples

### Compute Instance

```yaml
apiVersion: compute.cnrm.cloud.google.com/v1beta1
kind: ComputeInstance
metadata:
  name: instance-sample
  annotations:
    cnrm.cloud.google.com/project-id: "my-project-id"
spec:
  machineType: n1-standard-1
  zone: us-central1-a
  bootDisk:
    initializeParams:
      sourceImage: projects/debian-cloud/global/images/family/debian-11
  networkInterface:
    - networkRef:
        name: default
```

### Storage Bucket

```yaml
apiVersion: storage.cnrm.cloud.google.com/v1beta1
kind: StorageBucket
metadata:
  name: bucket-sample
spec:
  location: US
```

### Pub/Sub Topic & Subscription

```yaml
apiVersion: pubsub.cnrm.cloud.google.com/v1beta1
kind: PubSubTopic
metadata:
  name: order-events-topic
---
apiVersion: pubsub.cnrm.cloud.google.com/v1beta1
kind: PubSubSubscription
metadata:
  name: order-processor-sub
spec:
  topicRef:
    name: order-events-topic
  ackDeadlineSeconds: 30
```

Шаг 3: Внедрение инструмента инвентаризации

Создайте файл .agents/skills/kcc-ops/scripts/inventory.sh , чтобы обнаружить ресурсы KCC: 

#!/bin/bash
# List all resources in the cnrm.cloud.google.com group
KCC_KINDS=$(kubectl api-resources --no-headers | awk '/\.cnrm\.cloud\.google\.com/ {print $1}')
KCC_KINDS_CSV=$(echo "$KCC_KINDS" | paste -sd, -)

printf "%-40s %-30s %-10s %s\n" "KIND" "NAME" "READY" "STATUS/MESSAGE"
kubectl get "$KCC_KINDS_CSV" -A -o custom-columns="KIND:.kind,NAME:.metadata.name,READY:.status.conditions[?(@.type=='Ready')].status,MSG:.status.conditions[?(@.type=='Ready')].message" --ignore-not-found --no-headers

Шаг 4: Добавьте логику проверки политик.

Создайте файл .agents/skills/kcc-ops/scripts/vet-policy.sh . Этот скрипт будет использовать gator для проверки манифестов на соответствие политикам OPA: 

#!/bin/bash
MANIFEST=$1
SKILL_ROOT=$(dirname "$(dirname "$0")")
POLICY_SRC="$SKILL_ROOT/resources/policies"

echo "=== OPA/Gatekeeper Policy Vetting ==="
if command -v gator >/dev/null 2>&1; then
    gator test -f "$MANIFEST" -f "$POLICY_SRC/templates" -f "$POLICY_SRC/constraints"
else
    echo "Gator not found. Skipping OPA audit."
fi

Шаг 5: Внедрение защиты неизменяемых полей.

Это критически важный механизм безопасности. Создайте файл .agents/skills/kcc-ops/scripts/verify-immutable.sh : 

#!/bin/bash
MANIFEST=$1
KIND=$(grep "^kind:" "$MANIFEST" | awk '{print $2}')
NAME=$(grep "name:" "$MANIFEST" | head -n 1 | awk '{print $2}')

# Check for changes in common immutable fields
IMMUTABLE_FIELDS=("location" "project-id" "name" "zone" "region")
TEMP_FILE=$(mktemp)
kubectl get "$KIND" "$NAME" -o yaml > "$TEMP_FILE" 2>/dev/null

for field in "${IMMUTABLE_FIELDS[@]}"; do
    NEW=$(grep "$field:" "$MANIFEST" | awk '{print $2}')
    OLD=$(grep "$field:" "$TEMP_FILE" | awk '{print $2}')
    if [ -n "$NEW" ] && [ -n "$OLD" ] && [ "$NEW" != "$OLD" ]; then
        echo "🚨 WARNING: Immutable field '$field' is changing! Potential resource recreation."
    fi
done
rm "$TEMP_FILE"

Шаг 6: Аварийное восстановление (принудительное удаление)

Создайте файл .agents/skills/kcc-ops/scripts/force-delete.sh : 

#!/bin/bash
KIND=$1; NAME=$2; NS=${3:-default}
echo "Removing finalizers for $KIND/$NAME in $NS..."
kubectl patch "$KIND" "$NAME" -n "$NS" -p '{"metadata":{"finalizers":null}}' --type=merge
kubectl delete "$KIND" "$NAME" -n "$NS" --wait=false

Шаг 7: Завершение определения ресурсов

Сделайте все скрипты исполняемыми: 

chmod +x .agents/skills/kcc-ops/scripts/*.sh

10. Проверка новых навыков

А теперь начните новый разговор и проверьте свои навыки:

  1. Обнаружение : @kcc-ops Show me all KCC resources in my cluster.
  2. Проверка соответствия : Создайте файл bucket.yaml с объектом StorageBucket. Запросите у @kcc-ops Vet my bucket.yaml manifest.
  3. Безопасность : Попробуйте обновить location существующего бакета в bucket.yaml . Запросите информацию @kcc-ops Verify my bucket.yaml for immutable changes.

Обратите внимание, как агент разумно выбирает правильный сценарий и следует «золотому правилу» из вашего SKILL.md .

11. Обеспечение безопасности агента

Предоставление агенту искусственного интеллекта доступа к вашему терминалу — это мощный инструмент, но он требует контроля.

Зайдите в Antigravity - Настройки - Терминал и изучите список разрешенных и список запрещенных устройств .

  • Список разрешенных команд : добавьте сюда ls , kubectl get и ваши скрипты навыков.
  • Список запрещенных действий : добавьте sudo , rm -rf или другие деструктивные команды, чтобы гарантировать, что агент ВСЕГДА будет запрашивать разрешение.

12. Заключение

Поздравляем! Вы перешли от установки Antigravity к созданию высокоточного навыка управления KCC .

Вы узнали:

  • Как расширить функциональность агента с помощью пользовательских инструментов bash.
  • Как закодировать оперативные «золотые правила» в файл SKILL.md .
  • Как обеспечить безопасность при управлении сложной инфраструктурой.

Что дальше?

Расширьте папку resources/policies добавив больше ограничений OPA, или добавьте скрипт check-health.sh для автоматизации проверок готовности кластера!