Módulo 5: Securing The Ai Workload

4. Por qué Bedrock no necesita una API key

Siguiente →

Descripción

BedrockManifestExtractorRole (Módulo 3, lección 4) no tiene, en ningún lugar de su definición, un campo llamado api_key, secret, o token. La función extract-shipment-manifest-fields invoca bedrock:InvokeModel firmando la solicitud con las credenciales temporales que Lambda le entrega al asumir ese rol —el mismo mecanismo SigV4 que ya usa para leer de S3 o escribir en DynamoDB—, sin ningún secreto nuevo que crear, rotar, ni gestionar. Esta lección explica por qué eso es una ventaja real, no un detalle incidental, contrastándola con la forma en que la mayoría de las APIs de LLM de terceros exige exactamente lo contrario — y, con la misma honestidad que el resto de esta guía, nombra que AWS sí ofrece, desde 2025, un mecanismo alternativo de API keys para Bedrock, y por qué esta guía no lo usa.

Conexión con el módulo

Este módulo reusa el security gate de cloud-security-and-guardrails-guide sin ningún cambio — y esa guía, en su Módulo 3 completo, construyó la disciplina de gestión de secretos (SSM Parameter Store/Secrets Manager) para las credenciales que Andes Cargo sí necesita gestionar (la API de aduanas, por ejemplo). Esta lección es la contraparte honesta de ese trabajo: nombra, con precisión, una superficie de gestión de secretos que esta guía nunca tuvo que construir, y por qué.

La mayoría de las APIs de LLM de terceros exige un secreto que gestionar

Casi cualquier proveedor de modelos de lenguaje fuera del ecosistema de AWS —OpenAI, Anthropic directo (sin Bedrock), Google AI Studio, entre otros— autentica sus llamadas con una API key: un string largo, generado una vez, que el código tiene que guardar en algún lugar y enviar en cada solicitud, típicamente en un encabezado HTTP (Authorization: Bearer sk-...). Esa API key es, en los hechos, un secreto de larga duración: si se filtra —en un repositorio público, en un log, en una variable de entorno mal configurada—, cualquiera que la obtenga puede facturar contra la cuenta del dueño original hasta que alguien la revoque manualmente. Gestionar esa key correctamente exige la misma disciplina que cloud-security-and-guardrails-guide, Módulo 3, ya construyó para la API de aduanas de Andes Cargo: nunca en texto plano en el repositorio, rotación periódica, un gestor de secretos dedicado.

   FLUJO TÍPICO DE UNA API DE LLM DE TERCEROS

   código  --Authorization: Bearer sk-abc123...-->  API del proveedor
              │
              │  el secreto viaja en cada solicitud, tal cual
              │  si se filtra, sigue siendo válido hasta que
              │  alguien lo revoque a mano
              ▼
           superficie de fuga nueva, que hay que gestionar
           con el mismo cuidado que cualquier credencial

Bedrock, por defecto, no tiene esa superficie: la llamada la firma IAM

bedrock:InvokeModel, invocado de la forma en que extract-shipment-manifest-fields lo hace, nunca envía un secreto de larga duración en la solicitud. Lo que viaja es una firma SigV4 —un cálculo criptográfico derivado de credenciales temporales que AWS Security Token Service (STS) emitió cuando Lambda asumió BedrockManifestExtractorRole—, no el secreto mismo. La distinción importa en la práctica, no solo en la teoría:

   FLUJO DE extract-shipment-manifest-fields (esta guía)

   Lambda asume BedrockManifestExtractorRole
        │
        │  STS emite credenciales TEMPORALES (expiran solas,
        │  nunca se escriben en el código ni en el repositorio)
        ▼
   El SDK firma la solicitud con SigV4 -- el secreto en sí
   NUNCA viaja en la solicitud, solo la firma derivada de él
        │
        ▼
   bedrock:InvokeModel, evaluado contra la política de
   BedrockManifestExtractorRole -- exactamente el ARN acotado
   del Módulo 3, verificado con bedrock-least-privilege.rego
   (lección 3 de este módulo)

Esto no es una peculiaridad de Bedrock — es el mismo mecanismo IAM que Andes Cargo ya usa desde terraform-and-iac-guide para que process-shipment-manifest lea de S3 o escriba en DynamoDB, aplicado aquí, por primera vez, a la invocación de un modelo de lenguaje. Ninguna guía de este ecosistema necesitó nunca gestionar una "API key de S3" o una "API key de DynamoDB" — invocar Bedrock de esta forma hereda esa misma ausencia de superficie.

La honestidad exacta: AWS sí ofrece API keys para Bedrock desde 2025, y esta guía no las usa

Sería impreciso decir que Bedrock "nunca" tiene API keys — eso ya no es cierto. Desde julio de 2025, AWS ofrece un mecanismo alternativo, explícitamente diseñado para simplificar la integración con herramientas que esperan un modelo de autenticación tipo bearer token (el mismo patrón de OpenAI/Anthropic directo): "API keys for Amazon Bedrock enable developers to quickly generate access credentials directly within the Amazon Bedrock console or AWS SDK", con dos variantes —de corta duración ("valid for the duration of your console session, or up to 12 hours, whichever is shorter") y de larga duración ("give you the flexibility to define key validity duration")—, pensadas para eliminar la fricción de "manually configure IAM principals and policies" (fuente: AWS — Amazon Bedrock API keys, ver Recursos).

Esta guía no usa ese mecanismo, por una razón concreta, no por preferencia estética: adoptarlo reintroduciría exactamente la superficie de gestión de secretos que BedrockManifestExtractorRole evita por diseño. A diferencia de SigV4 —donde el secreto nunca viaja en la solicitud—, una bearer token de Bedrock sí viaja tal cual en cada llamada, el mismo patrón de riesgo que cualquier API key de terceros. La investigación de seguridad posterior al lanzamiento lo confirma con evidencia real, no hipotética:

  • Claves filtradas en repositorios públicos, en semanas, no meses. Investigadores de seguridad reportaron API keys de Bedrock filtradas públicamente dentro de las primeras dos semanas tras su disponibilidad, con una exposición estimada de hasta $18.000 dólares por día por región en cargos de LLMjacking —uso no autorizado de un modelo facturado a la cuenta de la víctima— si una clave de larga duración cae en manos equivocadas.
  • Un caso real, con fecha exacta. Entre el 4 de diciembre de 2025 y el 26 de enero de 2026, un fallo de implementación permitió que las claves de Bedrock de larga duración —construidas sobre Service Specific Credentials— evadieran la aplicación de políticas de control de servicio (SCP): "Denying the permission via SCP did not work for long-term keys". Un usuario IAM con permiso para el servicio subyacente podía crear una credencial de este tipo para sí mismo y saltarse una restricción organizacional que, con IAM/SigV4 tradicional, sí se habría aplicado. AWS corrigió el fallo el 29 de enero de 2026, nueve días después de reportado, y declaró no haber identificado clientes afectados (fuente: Sonrai Security, ver Recursos).

Ninguno de los dos hallazgos dice que las API keys de Bedrock sean, en sí mismas, una mala herramienta para todo contexto —AWS las diseñó para un caso de uso real: integrar Bedrock rápido con herramientas que ya hablan el protocolo bearer token de OpenAI, sin tener que aprender IAM primero—. Dicen, con precisión, que para esta carga de trabajo específica, donde BedrockManifestExtractorRole ya existe, ya está acotado por mínimo privilegio (lección 2 de este módulo), y ya se verifica automáticamente (lección 3), adoptar un mecanismo de bearer token adicional no resolvería ningún problema real de Andes Cargo — y sí agregaría, de vuelta, exactamente la superficie que esta guía evitó desde el Módulo 3: un secreto que gestionar, rotar, y proteger de una fuga.

Por qué esto importa para el security gate de este módulo

El resto de este módulo —la política Rego de la lección 3, el escaneo de Trivy de la lección 5, la firma de cosign de la lección 6— existe para verificar infraestructura declarada y artefactos firmados. Ninguna de esas tres herramientas está diseñada para vigilar la rotación de un secreto de larga duración, porque este proyecto nunca introdujo uno para invocar Bedrock. Si Andes Cargo hubiera elegido el camino de API keys, este módulo habría necesitado una pieza adicional completa —el mismo tipo de disciplina que cloud-security-and-guardrails-guide, Módulo 3, ya construyó para la API de aduanas—: dónde se almacena la clave, quién puede leerla, cada cuánto se rota, qué pasa si se filtra. Ninguna de esas preguntas tiene una respuesta que este módulo necesite dar, porque la pregunta misma no aplica.

Errores comunes

Afirmar, sin matices, que "Bedrock nunca tiene API keys" (de generalizar una decisión de diseño de esta guía como si fuera una limitación técnica del servicio). Qué pasa: alguien, después de leer la primera mitad de esta lección, repite en una entrevista o en una conversación técnica que Bedrock, como servicio, no soporta autenticación por API key. Cómo detectarlo: si tu explicación de esta lección no menciona el mecanismo de API keys que AWS lanzó en julio de 2025. Cómo corregirlo: la afirmación correcta y completa es que esta carga de trabajo específica, con BedrockManifestExtractorRole ya construido, no necesita una —no que el servicio carezca de la opción. La sección de honestidad de esta lección existe exactamente para esta distinción.

Asumir que las API keys de Bedrock son inherentemente inseguras, sin contexto de para qué se diseñaron. Qué pasa: alguien, viendo los dos hallazgos de seguridad citados, concluye que AWS lanzó una función defectuosa que nadie debería usar nunca. Cómo detectarlo: si tu conclusión de esta lección es "las API keys de Bedrock son un error de AWS", en vez de "no son la elección correcta para esta carga específica". Cómo corregirlo: el fallo del período diciembre 2025-enero 2026 fue un bug de implementación de la aplicación de SCP, ya corregido — no una falla conceptual del mecanismo. Las API keys de Bedrock siguen siendo una opción razonable para el caso de uso que AWS declaró (integración rápida con herramientas bearer-token), simplemente no es el caso de uso de extract-shipment-manifest-fields, que ya tiene un rol IAM acotado y verificado.

Confundir "SigV4 firma la solicitud" con "no hay ninguna credencial involucrada" (de simplificar de más). Qué pasa: alguien concluye que, porque no hay una API key visible, Bedrock se invoca "sin credenciales de ningún tipo". Cómo detectarlo: si tu explicación de esta lección no menciona que STS sigue emitiendo credenciales temporales. Cómo corregirlo: sí hay credenciales —STS las emite cada vez que Lambda asume el rol—, la diferencia es que son temporales (expiran solas, sin necesitar rotación manual) y nunca viajan en la solicitud (solo la firma derivada de ellas viaja). "Sin secreto que gestionar" no significa "sin ninguna credencial" — significa que el mecanismo de credenciales no exige la disciplina operativa de un secreto de larga duración.

Ejercicios

Ejercicio 1 — Explica, en una frase, la diferencia entre "el secreto viaja en la solicitud" (API key típica) y "solo una firma derivada del secreto viaja" (SigV4). Un colega pregunta por qué esa distinción, aparentemente técnica, tiene consecuencias de seguridad reales.

Ver solución

Con una API key típica, si alguien intercepta o accede a una sola solicitud —un log mal configurado, un proxy comprometido—, obtiene el secreto completo y puede reutilizarlo indefinidamente hasta que alguien lo revoque. Con SigV4, cada firma es válida solo para esa solicitud específica (el algoritmo incorpora la fecha, el método, la ruta y otros parámetros de esa llamada exacta) — interceptar una firma no le da a nadie la capacidad de firmar solicitudes futuras, porque el secreto subyacente (las credenciales temporales de STS) nunca se transmitió, solo se usó localmente para calcular la firma.

Ejercicio 2 — Basándote en el caso real de diciembre 2025-enero 2026, explica por qué un fallo de aplicación de SCP en las API keys de larga duración es un riesgo que SigV4/IAM tradicional no comparte de la misma forma. ¿Qué habría sido distinto si BedrockManifestExtractorRole, en vez de una API key, hubiera estado sujeto a esa misma SCP?

Ver solución

Una SCP (Service Control Policy) actúa como un límite organizacional que se evalúa contra la identidad IAM que hace la llamada — con IAM/SigV4 tradicional, esa identidad es el rol mismo (BedrockManifestExtractorRole), y la SCP se aplica de forma directa y ya probada por AWS durante años. El fallo real del período citado ocurrió porque las API keys de larga duración se implementan como Service Specific Credentials ligadas a un usuario IAM, y la evaluación de la SCP contra esa credencial específica tenía un hueco —no contra el usuario IAM en sí, sino contra la credencial derivada—. BedrockManifestExtractorRole, al no usar ese mecanismo, nunca estuvo expuesto a esa clase específica de fallo, simplemente porque el camino de código que lo contenía nunca se ejecuta para esta carga de trabajo.

Ejercicio 3 — Diseña, en prosa, un escenario legítimo donde Andes Cargo SÍ debería considerar las API keys de Bedrock, a pesar de todo lo que esta lección explicó. Piensa en el caso de uso que AWS declaró como el propósito original del mecanismo.

Ver solución

Una respuesta razonable: si Andes Cargo quisiera darle a un equipo externo de desarrollo —un contratista de un prototipo rápido, por ejemplo— acceso de prueba a Bedrock usando una herramienta que ya habla el protocolo bearer token de OpenAI (una biblioteca de terceros, un notebook de experimentación rápida), sin tener que enseñarles primero cómo configurar un rol IAM y asumirlo correctamente, una API key de corta duración (máximo 12 horas, según la fuente citada) podría ser una elección razonable para ese contexto específico y acotado en el tiempo — nunca para una carga de producción como extract-shipment-manifest-fields, que corre de forma continua, sin un humano interactivo de por medio, y donde el rol IAM ya existe y ya está verificado por el gate de este módulo.

Resumen y siguiente paso

Esta lección contrastó el modelo de autenticación por defecto de extract-shipment-manifest-fields —SigV4, firmado con credenciales temporales de STS emitidas al asumir BedrockManifestExtractorRole, sin ningún secreto que viaje en la solicitud— con el patrón de API key que exige la mayoría de las APIs de LLM de terceros. Con la misma honestidad del resto de esta guía, nombraste que AWS sí ofrece un mecanismo alternativo de API keys para Bedrock desde julio de 2025, y viste dos hallazgos reales de seguridad —claves filtradas dentro de dos semanas del lanzamiento, y un fallo de aplicación de SCP entre diciembre de 2025 y enero de 2026, ya corregido— que explican por qué esta guía, deliberadamente, no lo usa para esta carga de trabajo.

Antes de avanzar deberías poder: explicar la diferencia entre "el secreto viaja" y "solo la firma viaja"; nombrar el mecanismo alternativo de API keys de Bedrock y el caso de uso para el que AWS lo diseñó; y justificar, con evidencia, por qué BedrockManifestExtractorRole es la elección correcta para extract-shipment-manifest-fields específicamente.

La lección 5 vuelve al código: trivy config, corrido de verdad sobre bedrock.tf y modules/bedrock-guardrail/, el segundo control del security gate heredado aplicado a la infraestructura de IA de este módulo.

Recursos

  1. AWS — Amazon Bedrock introduces API keys for streamlined development — la fuente oficial del mecanismo de API keys de Bedrock, incluida la cita textual usada en esta lección.
  2. Sonrai Security — Cracks in the Bedrock: Bypassing SCP Enforcement with Long-Lived API Keys — el caso real de diciembre 2025-enero 2026 citado en esta lección, con la fecha exacta del fallo y su corrección.
  3. AWS Docs — Authentication and access control for Amazon Bedrock — referencia oficial del modelo de autenticación IAM/SigV4 que BedrockManifestExtractorRole usa.
  4. Módulo 3, lección 4 de esta guía (04-hands-on-bedrockmanifestextractorrole-least-privilege.md) — la construcción original del rol cuyo mecanismo de autenticación esta lección explica.
← Anterior3. Manos a la obra: `bedrock-least-privilege.rego`, agregada a `policy/`Siguiente →5. Manos a la obra: Trivy sobre el Terraform nuevo