Maîtriser les opérations KCC avec Google Antigravity

1. Introduction

Dans cet atelier de programmation, vous découvrirez Google Antigravity (appelé Antigravity dans le reste du document), une plate-forme de développement agentique qui fait évoluer l'IDE vers l'ère agentique.

Contrairement aux assistants de codage standards qui ne font qu'autocompléter les lignes, Antigravity fournit un "contrôle de mission" pour gérer les agents autonomes qui peuvent planifier, coder et même naviguer sur le Web pour vous aider à créer.

Antigravity est conçu comme une plate-forme agentique. Il suppose que l'IA n'est pas seulement un outil d'écriture de code, mais un acteur autonome capable de planifier, d'exécuter, de valider et d'itérer des tâches d'ingénierie complexes avec une intervention humaine minimale.

Points abordés

• Installation et configuration d'Antigravity
• Découverte des concepts clés d'Antigravity, tels que le gestionnaire d'agents, l'éditeur, le navigateur, etc.
• Création d'une compétence KCC Ops de qualité production à partir de zéro pour gérer les ressources Google Cloud en toute sécurité et en conformité

Prérequis

Antigravity est actuellement disponible en preview pour les comptes Gmail personnels. Il est fourni avec un quota sans frais pour utiliser les modèles premium.

Antigravity doit être installé localement sur votre système. Le produit est disponible sur Mac, Windows et certaines distributions Linux. En plus de votre propre machine, vous aurez besoin des éléments suivants :

• Un compte Gmail (compte Gmail personnel)
• Un compte Google Cloud et un projet Google Cloud
• Un navigateur Web tel que Chrome compatible avec la console Google Cloud et Cloud Shell

2. Préparation

Configuration du projet

Créer un projet Google Cloud

1. Dans la console Google Cloud, sur la page du sélecteur de projet, sélectionnez ou créez un projet Google Cloud.
2. Assurez-vous que la facturation est activée pour votre projet Cloud. Découvrez comment vérifier si la facturation est activée sur un projet.

Cet atelier de programmation s'adresse aux utilisateurs et aux développeurs de tous niveaux (y compris aux débutants).

3. Installation

Si Antigravity n'est pas déjà installé, commençons par l'installer. Le produit est actuellement disponible en preview. Vous pouvez utiliser votre compte Gmail personnel pour commencer.

Accédez à la page de téléchargement et cliquez sur la version du système d'exploitation appropriée à votre cas. Lancez le programme d'installation de l'application et installez-la sur votre machine. Une fois l'installation terminée, lancez l'application Antigravity.

Principales étapes de la configuration :

• Choisir le flux de configuration : nous vous recommandons de repartir de zéro pour cet atelier de programmation.
• Développement axé sur l'examen (recommandé) : choisissez cette option. Elle permet à l'agent de prendre une décision et de revenir vers l'utilisateur pour approbation, ce qui est essentiel pour les opérations d'infrastructure.

Ensuite, configurez votre éditeur et connectez-vous à Google. Enfin, acceptez les conditions d'utilisation.

4. Configuration de l'infrastructure : GKE et Config Connector

Avant de pouvoir créer la compétence, vous avez besoin d'un environnement Google Cloud avec Config Connector (KCC) installé manuellement et configuré en mode espace de noms. Cela vous permet de gérer les ressources GCP en tant qu'objets Kubernetes.

Étape 0 : Préparer votre environnement

1. Prérequis pour les clusters

Créez un cluster GKE avec les fonctionnalités nécessaires activées :

# 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. Installer l'opérateur Config Connector

L'opérateur maintient votre installation à jour.

# 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. Configurer le mode espace de noms

Créez une ressource ConfigConnector pour spécifier le mode de fonctionnement.

# 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. Créer une identité et un espace de noms

Pour cet atelier, nous allons utiliser l'espace de noms default et un compte de service Google (GSA) dédié.

# 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. Configurer l'espace de noms

Créez un ConfigConnectorContext pour surveiller l'espace de noms.

# 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. Vérifier l'installation

Attendez que le contrôleur soit prêt pour l'espace de noms 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. Gestionnaire d'agents : contrôle de mission

Antigravity est basé sur la fondation Open Source Visual Studio Code (VS Code), mais modifie radicalement l'expérience utilisateur pour donner la priorité à la gestion des agents plutôt qu'à l'édition de texte. L'interface est divisée en deux fenêtres principales distinctes : le Editor et le Agent Manager.

Gestionnaire d'agents

Lorsqu'il lance Antigravity, l'utilisateur est généralement accueilli par le gestionnaire d'agents. Cette interface fait office de tableau de bord de contrôle de mission. Elle est conçue pour l'orchestration de haut niveau, ce qui permet aux développeurs de générer, de surveiller et d'interagir avec plusieurs agents fonctionnant de manière asynchrone dans différents espaces de travail ou tâches.

Dans cette vue, le développeur agit en tant qu'architecte. Il définit des objectifs de haut niveau. Chacune de ces requêtes génère une instance d'agent dédiée. L'interface utilisateur fournit une visualisation de ces flux de travail parallèles, affichant l'état de chaque agent, les artefacts qu'il a produits (plans, résultats, différences) et toutes les demandes d'approbation humaine en attente.

6. Navigateur et artefacts Antigravity

Antigravity crée des artefacts lorsqu'il planifie et effectue son travail. Il s'agit de fichiers Markdown enrichis, de diagrammes d'architecture, d'images, d'enregistrements de navigateur et de différences de code.

Les artefacts résolvent le "déficit de confiance"

Lorsqu'un agent affirme "J'ai corrigé le bug", le développeur devait auparavant lire le code pour vérifier. Dans Antigravity, l'agent produit un artefact pour le prouver.

Artefacts

Voici les principaux artefacts produits par Antigravity :

• Task Lists : plan structuré généré avant l'écriture du code.
• Implementation Plan : modifications architecturées avec des détails techniques.
• Walkthrough : résumé des modifications et de la manière de les tester.
• Browser Recordings : enregistrements vidéo des sessions de navigateur pour la validation de l'interface utilisateur.

Navigateur Antigravity

Lorsque l'agent doit interagir avec le Web, il appelle un sous-agent de navigateur. Ce sous-agent peut cliquer, faire défiler, saisir et lire les journaux de la console. Il utilise un modèle spécialisé pour fonctionner sur les pages ouvertes dans le navigateur géré par Antigravity.

7. Expérience de l'éditeur

L'éditeur conserve la familiarité de VS Code. Il inclut l'explorateur de fichiers standard, la coloration syntaxique et l'écosystème d'extensions.

Principales fonctionnalités de l'éditeur :

• Autocomplétion : suggestions intelligentes acceptées en appuyant sur la touche Tabulation.
• Tabulation pour importer : suggère d'ajouter des dépendances manquantes.
• Commandes (Cmd + I) : déclenchent des complétions en ligne à l'aide du langage naturel.
• Panneau latéral de l'agent (Cmd + L) : activez ou désactivez le panneau de l'agent pour poser des questions ou faire référence à des fichiers à l'aide de @.

8. Commentaires

La capacité d'Antigravity à recueillir facilement vos commentaires est au cœur de son fonctionnement. Ces artefacts vous permettent de fournir des commentaires à l'agent dans le style des commentaires Google Docs.

Chaque fois que vous ajoutez un commentaire à un plan ou à une tâche, n'oubliez pas de l'envoyer. Cela permet de guider l'agent dans la direction souhaitée.

9. Créer la compétence KCC Ops

Maintenant que vous comprenez la plate-forme, créons la compétence KCC Ops.

Kubernetes Config Connector (KCC) vous permet de gérer les ressources GCP en tant qu'objets K8s. Toutefois, il nécessite des garde-fous pour éviter la dérive de configuration, les violations de conformité et la recréation accidentelle de ressources.

Étape 1 : Structurer la compétence

Dans la racine de votre espace de travail, créez la structure de répertoire pour votre compétence :

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

Étape 2 : Créer le fichier SKILL.md (le cerveau)

Le fichier SKILL.md définit les métadonnées et la "règle d'or" de base pour l'agent. Créez .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
```

Étape 3 : Implémenter l'outil d'inventaire

Créez .agents/skills/kcc-ops/scripts/inventory.sh pour découvrir les ressources 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

Étape 4 : Ajouter la logique de validation des règles

Créez .agents/skills/kcc-ops/scripts/vet-policy.sh. Ce script utilisera gator pour valider les manifestes par rapport aux règles 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

Étape 5 : Implémenter la protection des champs immuables

Il s'agit d'un garde-fou essentiel. Créez .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"

Étape 6 : Récupération d'urgence (suppression forcée)

Créez .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

Étape 7 : Finaliser les ressources

Exécutez tous les scripts :

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

10. Tester votre nouvelle compétence

Démarrez une nouvelle conversation et testez votre compétence :

1. Découverte : @kcc-ops Show me all KCC resources in my cluster.
2. Conformité : créez un fichier bucket.yaml avec un StorageBucket. Demandez : @kcc-ops Vet my bucket.yaml manifest.
3. Sécurité : essayez de mettre à jour le location d'un bucket existant dans bucket.yaml. Demandez : @kcc-ops Verify my bucket.yaml for immutable changes.

Notez comment l'agent sélectionne intelligemment le script approprié et suit la "règle d'or" de votre fichier SKILL.md.

11. Sécuriser l'agent

Donner à un agent IA l'accès à votre terminal est puissant, mais nécessite des contrôles.

Accédez à Antigravity > Settings > Terminal (Antigravity > Paramètres > Terminal) et explorez la liste d'autorisation et la liste de refus.

• Liste d'autorisation : ajoutez ici ls, kubectl get et les scripts de votre compétence.
• Liste de refus : ajoutez sudo, rm -rf ou d'autres commandes destructrices pour vous assurer que l'agent DEMANDE TOUJOURS l'autorisation.

12. Conclusion

Félicitations ! Vous êtes passé de l'installation d'Antigravity à la création d'une compétence KCC Operations haute fidélité.

Vous avez appris à :

• étendre l'agent avec des outils bash personnalisés ;
• encoder des "règles d'or" opérationnelles dans un fichier SKILL.md ;
• fournir des garde-fous pour la gestion d'infrastructures complexes.

Et ensuite ?

Développez votre dossier resources/policies avec davantage de contraintes OPA ou ajoutez un script check-health.sh pour automatiser les vérifications de préparation du cluster.