Google Cloud (alleen-lezen)

Je kunt hier ook gewoon om vragen. Vraag Command Center "is Google Cloud gekoppeld?" en hij rapporteert uit welk GCP-project elke koppeling leest, als welk serviceaccount hij optreedt, of hij op dit moment werkt per capability (logs, error reporting, BigQuery), en of de agents hem mogen gebruiken. Een koppeling zonder toegestane datasets is verbonden en kan niets bevragen — dat is meestal het antwoord op "hij ziet niets". De sleutel plakken blijft hier: een credential hoort nooit door een chattranscript te reizen.

Wat het is

Als er een bugmelding binnenkomt, is de vraag meestal "wat deed productie eigenlijk?" — en het antwoord staat in je logs, niet in het ticket. Met deze koppeling leest FixControl een begrensd stukje van je Google Cloud-telemetrie en legt dat voor aan de agent die over de bug redeneert.

Hij leest. Hij kan niet schrijven. Er zit helemaal geen schrijfpad in.

Open het bij Instellingen → Kanalen → Databronnen → Google Cloud (read-only). Je moet admin van je FixControl-organisatie zijn.

Wat hij leest

Wees duidelijk over die laatste regel: de BigQuery-helft is gebouwd, bewaakt, van kostenhekken voorzien en wordt door de verbindingstest uitgeoefend, maar niets in het product gebruikt hem. Vul de dataset-allowlist als je de capability groen bewezen wilt zien; bouw er geen workflow omheen tot een scherm erom vraagt.

Alleen-lezen, vier keer

Alleen-lezen is hier geen belofte; het zijn vier onafhankelijke mechanismen, en elk ervan zou op zichzelf genoeg zijn:

1. Het token kan niet schrijven. FixControl maakt Google-accesstokens met alleen-lezen scopes, en maakt ze per dienst — een aanvraag aan Cloud Logging draagt dus nooit een credential dat bij BigQuery kan. Er komt nergens in de koppeling een schrijfscope voor.
2. De endpoints kunnen niet schrijven. Alleen list-, get- en query-endpoints worden aangeroepen.
3. De query kan niet schrijven. Een BigQuery-statement moet één SELECT zijn (of WITH … SELECT). INSERT, UPDATE, DELETE, MERGE, TRUNCATE, CREATE, ALTER, DROP, GRANT, REVOKE, EXPORT, LOAD en de transactiewerkwoorden worden botweg geweigerd, en elke genoemde tabel moet binnen je dataset-allowlist vallen.
4. De kosten kunnen niet weglopen. Een query wordt eerst als dry run gedraaid en geweigerd als hij meer zou scannen dan je plafond, en de echte run draagt dat plafond als harde limiet.

Inrichten

Je plakt een service-account JSON-sleutel. Er is voor deze koppeling geen OAuth-toestemmingsscherm; het is een machine-identiteit die jij beheert, en die je in Google Cloud kunt intrekken zonder FixControl aan te raken.

Geef dat serviceaccount het minimum:

• roles/logging.viewer
• roles/errorreporting.viewer
• voor BigQuery: roles/bigquery.jobUser en roles/bigquery.dataViewer

De sleutel wordt per workspace versleuteld opgeslagen en wordt door geen enkele API teruggegeven — het scherm toont alleen het serviceaccount-adres waar hij bij hoort, en of er een sleutel aanwezig is.

Test de verbinding — deze stap is niet optioneel

Een nieuwe koppeling wordt opgeslagen als Nog niet geverifieerd, en elke lezing weigert een koppeling die niet geverifieerd is. Test connection is wat een opgeslagen sleutel bruikbaar maakt. Tot die test slaagt zegt het scherm dat, en wordt er niets gelezen.

De test is geen ping. Hij beproeft elke capability apart, via dezelfde endpoints, dezelfde scopes en dezelfde host-allowlist die de echte lezingen gebruiken, met paginagrootte één — een groen resultaat betekent dus dat de echte lezing zou werken, niet dat er ergens een Google-endpoint antwoordde:

Een beheerder die Logging wél maar Error Reporting niet heeft verleend, ziet precies dat, op een eigen regel, in plaats van één rode badge over de hele koppeling.

De probe is alleen-lezen net als al het andere hier: er wordt geen schrijfscope gevraagd en geen schrijf-endpoint aangeroepen.

Statussen

Sleutel roteren, uitschakelen, verwijderen

• Roteren doe je door een nieuwe sleutel te plakken. Gecachte accesstokens en de gecachte datasetlijst worden meteen weggegooid, zodat de oude sleutel per direct niet meer gebruikt wordt in plaats van aan het eind van zijn cacheduur. Draai daarna de test opnieuw.
• Uitschakelen stopt alle lezingen en alle health-probes en houdt de configuratie. Dit is de omkeerbare.
• Disable & delete vernietigt de opgeslagen sleutel. Het scherm zegt dat voordat je bevestigt, en wijst je op uitschakelen als alternatief.

Elk van deze handelingen gaat het auditspoor in, inclusief of de sleutel geroteerd is.

De velden

Let op de asymmetrie tussen de twee allowlists, want die is bewust: BigQuery is standaard-weigeren (een query noemt zijn eigen tabellen, dus een lege lijst moet "geen" betekenen), terwijl de log-allowlist een versmallend filter is (leeg betekent de logs van het project, die het credential toch al kon lezen).

Er komt niets geheims terug

Alles wat de koppeling teruggeeft gaat door twee maskeerrondes voordat het wordt opgeslagen, in een prompt gezet of getoond:

• Op veldnaam — alles waarvan de sleutel op een identiteit of een credential lijkt (e-mail, telefoon, wachtwoord, secret, token, api key, access/refresh/id token, authorization, cookie, session id, private key, client secret, burgerservicenummer, kaartnummer, CVV, IBAN, bankrekening) wordt vervangen door [redacted].
• Op waarde — dezelfde scanner voor geheim-vormige waarden die de sandbox op zijn logs gebruikt, loopt over wat overblijft.

Googles eigen foutmeldingen worden gemaskeerd voordat ze een foutbericht worden, zodat een mislukte aanroep niet kan lekken wat een geslaagde zou verbergen.

De doorloop is ook begrensd: diep geneste structuren stoppen bij een dieptemarkering, en lange lijsten stoppen met een telling van wat is weggelaten. Je weet altijd dat er iets is afgekapt, in plaats van een plausibel ogend geheel te zien.

Hoe het er op een ticket uitziet

Op een BUG-issue waarvan de patch door QA gaat, en alleen als de koppeling verbonden is en Allow AI GCP context aan staat, krijgt de QA-notitie een sectie met de kop Google Cloud diagnostics (read-only):

• Error Reporting — top groups, als tabel met aantal, gebruikers, service, laatst gezien en titel;
• Cloud Logging — newest first, met een regel die zegt hoeveel regels er zijn gelezen, of de set is afgekapt, en dat geheimen gemaskeerd zijn; daarna de regels zelf met tijdstempel en severity.

Kon een dienst niet bereikt worden, dan zegt de notitie dat op de plek van het blok — "Cloud Logging unavailable (code): message" — in plaats van de sectie weg te laten en de afwezigheid te laten lezen als "er was niets aan de hand".

Het standaardfilter is severity ERROR en hoger, over een venster van maximaal 72 uur. De leesvolumes zijn begrensd: hooguit 100 logregels en 128 KiB per lezing, hooguit 25 foutgroepen.

Elke samenstelling wordt in het auditspoor vastgelegd met de koppeling, het aantal foutgroepen en het aantal logregels.

Grenzen om te kennen voor je erop leunt

• Hij staat op drie onafhankelijke plekken uit. FixControl moet de koppeling voor je workspace hebben ingeschakeld (vraag je FixControl-contactpersoon), de koppeling moet Verbonden zijn (wat betekent dat de test geslaagd is), en Allow AI GCP context moet aan staan. Mis er één en de agent blijft blind.
• Eén koppeling per lezing. Zijn er meerdere ingericht, dan wordt de eerste geschikte gebruikt.
• Alleen BUG-issues. Een featureverzoek of een supportvraag haalt geen Google Cloud-context op.
• BigQuery heeft nog geen scherm (zie hierboven).
• Afkappen is zichtbaar, nooit stil. Een begrensde lezing zegt dat hij begrensd was.

Gerelateerd: Databasekoppeling · Wijzigingsvalidatie · Beveiliging & audit · Overzicht integraties