[Bug] gemini-enterprise: gem4gov says Knowledge Graph must be disabled for FedRAMP High, IL4, and IL5, but leaves Private Knowledge Graph on

Abierto
  • ¿Algo no está bien?
#402 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
1-2 días
Aptitud para principiantes
56/100
Tipo de issue
Error
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
google-cloud, python, terraform
Área
backend, cloud, security

Línea de trabajo

Start by reading blueprints/gemini-enterprise/gem4gov-cli/gem4gov.py, especially configure_gemini_enterprise_for_regime and its engine patch, then compare the FedRAMP High, IL4, IL5, and FedRAMP Moderate paths with the linked Google deployment guidance. Check whether the Terraform engine resource in discovery-engine.tf also needs the setting for new deployments. Done means the applicable compliance paths explicitly disable Private Knowledge Graph and the CLI guidance matches the supported settings.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

Bug Framework - FedRAMP High Framework - FedRAMP Moderate Framework - IL4 Framework - IL5 Gemini - Enterprise Gemini - Government Level of Effort - Low Priority - Medium Scope - Blueprint Scope - Fast

Bug Description

gem4gov onboard and gem4gov app update-compliance tell the operator that Knowledge Graph must be disabled, and neither one disables it.

Before it applies the FedRAMP High profile, gem4gov.py prints this list. The IL4 and IL5 paths print the same line:

Gemini Enterprise contains default features that are not yet authorized for FedRAMP High and must be disabled. These features are currently:
...
- Knowledge Graph / People Connectors

The profile it then applies does not include that setting. knowledgeGraphConfig appears nowhere in gem4gov.py, engine_features.yaml, or gemini-stage-0, and the google_discovery_engine_search_engine resource in discovery-engine.tf sets no knowledge_graph_config. So the engine keeps the value the API gave it, and Private Knowledge Graph stays on.

Google's Deployment guidance for Gemini for Government lists Private Knowledge Graph under Unauthorized features that you should disable manually, and its Turn off Private Knowledge Graph section gives the API call.

Environment and Deployment Context

  • Stellar Engine Version/Commit: Read on engines deployed at v4.0.0 (6d7d08c0). The code is the same at v5.2.0 (82153050) and main @ 2267b973, but no engine was deployed at those versions. blueprints/gemini-enterprise/gem4gov-cli/gem4gov.py at v5.2.0: the message at lines 1146, 1190, 1220, 1418, 1450, and 1480; the engine patch at lines 3290-3291.
  • Deployment Type:
    • US Region Restricted (e.g., Access Policy constraint)
    • FedRAMP Moderate
    • FedRAMP High
    • DoD IL4
    • DoD IL5
    • Stand-alone / Custom
  • FAST Stage (if applicable): Not applicable. blueprints/gemini-enterprise.

Steps to Reproduce

  1. Deploy gemini-stage-0 with compliance_regime = "FEDRAMP_HIGH".
  2. Apply the profile: 
    gem4gov app update-compliance --project-id <project> --engine-id <engine> --compliance-regime FEDRAMP_HIGH
  3. Read the engine: 
    curl -s -H "Authorization: Bearer $(gcloud auth print-access-token)" \
  -H "x-goog-user-project: <project>" \
  "https://us-discoveryengine.googleapis.com/v1alpha/projects/<project>/locations/us/collections/default_collection/engines/<engine>" \
  | jq .knowledgeGraphConfig

Expected Behavior

After the profile is applied for FedRAMP High, IL4, or IL5, enablePrivateKnowledgeGraph reads false, as the CLI's message says it must.

Actual Behavior

{
  "enablePrivateKnowledgeGraph": true,
  "featureConfig": {}
}

Four engines deployed with FEDRAMP_HIGH read this way after update-compliance ran. At v4.0.0 that command's engine patch was rejected (#259), but the patch has never carried this field, so the fix for #259 does not change the result.

Relevant Logs and Errors

None. The run prints the message above and finishes, and nothing reports that the setting was left on.

Additional Context

  • Leaving the field out does not turn it off. An engine created with POST .../engines and no knowledgeGraphConfig in the body also reads enablePrivateKnowledgeGraph: true, although the API reference says "Defaults to false if not specified." Google's Knowledge Graph page says "Knowledge Graph configurations are enabled for all Gemini Enterprise apps." The value has to be set explicitly.
  • Effect on a fresh deployment. The same page says "Without connecting people data, these features don't function properly," and the blueprint configures no People connector, so the practical effect may be small until someone adds one. The setting is on either way, and an assessor reading the engine sees it on.
  • Suggested fix, not tested. Add the field to the engine patch in configure_gemini_enterprise_for_regime (gem4gov.py lines 3290-3291), using the same mask Google's guidance shows: 
    engine_patch_body = {
    "features": engine_features.get("features"),
    "knowledgeGraphConfig": {
        "enablePrivateKnowledgeGraph": False,
        "enableCloudKnowledgeGraph": False,
    },
}
engine_update_mask = "features,knowledgeGraphConfig"
    FedRAMP Moderate calls the same function and prints no such list, so this may need to depend on the regime. Setting knowledge_graph_config in gemini-stage-0 would cover new engines, but not engines that already exist.
  • Side effect to expect. Google's page says "Disabling it deletes internal derived data and removes query annotations, reducing search accuracy and richness."
  • The message itself may need a look. It also lists Model Armor, which Google's guidance now shows as Authorized for FedRAMP High, so the two lists have drifted apart.
Lenguaje dominante
HCL
Estrellas
61
Forks
28
Merge medio
1 d 17 h
PR fusionados (30 d)
74

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de google/stellar-engine

Todos los issues de google/stellar-engine

Issues similares

Más issues de Backend & API Design

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.