DEV Community: Bianca Torres

Karpenter en el mundo cloud native: lo que conté en KubeFest #3

Bianca Torres — Mon, 26 Oct 2026 22:38:59 +0000

El pasado 24 de Octubre dí la charla "Karpenter en el mundo cloud native" en KubeFest #3, un evento organizado por la comunidad Platform Engineering Perú. Me gustó mucho el ambiente: habían personas que operan Kubernetes en su trabajo y al final salieron preguntas muy buenas.

Quería dejar por escrito lo que conté, para quien no pudo ir o para quien quiera revisar los ejemplos con más calma.

Todo empieza con un pod en Pending

¿A quién no le ha pasado?. Haces el deploy, parece que todo está bien, y un pod se queda en Pending. Revisas el clúster, hay nodos, hay recursos libres... y el pod sigue sin arrancar.

Pending quiere decir que el scheduler todavía no encuentra un nodo donde ponerlo. Lo que confunde es que el scheduler no mira el espacio libre total del clúster, mira nodo por nodo. Si un pod pide 2 CPU y tienes tres nodos con 1 CPU libre cada uno, en total hay 3 CPU libres, pero el pod no entra en ninguno. Y a eso súmale que puede necesitar una zona específica, una arquitectura o un tipo de nodo en particular.

$ kubectl describe pod web-6f9c
Events:
  Type     Reason            Message
  Warning  FailedScheduling  0/3 nodes are available: 3 Insufficient cpu.

Algo super importante: si realmente falta capacidad, un autoscaler puede crear nodos. Pero si el problema está en la configuración del pod, por más nodos que agregues va a seguir esperando.

¿Y dónde entra Karpenter?

Karpenter vive al costado del clúster. Por un lado está pendiente de la API de Kubernetes para detectar pods que no se pueden programar. Por el otro, le pide máquinas nuevas a Amazon EC2.

Algo que quise recalcar durante la charla: Karpenter no reemplaza al scheduler. Él consigue las máquinas, pero quien decide en qué nodo va cada pod sigue siendo Kubernetes.

Antes: Cluster Autoscaler y sus grupos

Antes de Karpenter, lo más común en AWS era usar Cluster Autoscaler. Funciona con grupos de nodos que defines de antemano (en EKS son Auto Scaling Groups), cada uno con su tipo de instancia y su mínimo y máximo. Por ejemplo, un grupo general con m5.large, otro de memoria con r5.xlarge, otro con GPU, y así.

Cuando ve pods pendientes, se pregunta si agregando un nodo a alguno de esos grupos el pod entraría. Si la respuesta es sí, escala ese grupo.

Cluster Autoscaler funciona bien y es muy usado. El tema es cuando tienes muchas aplicaciones con necesidades distintas: cada combinación de tamaño, arquitectura o GPU termina siendo un grupo más, y cada grupo hay que configurarlo y mantenerlo. Ahí surge la pregunta que da pie a nuestro tema central: ¿y si en vez de preparar grupos, la capacidad se eligiera según lo que piden los pods?

Lo que propone Karpenter

Karpenter le da la vuelta. La aplicación dice lo que necesita (memoria, arquitectura, si puede correr en Spot) y nosotros definimos en un NodePool qué tipos de instancias permitimos y con qué límites. Con eso, más lo que AWS tenga disponible en ese momento, Karpenter lanza el nodo que hace falta.

Ahora, tampoco es magia. No siempre va a elegir la máquina más barata y no puede garantizar que una instancia esté disponible, tambien depende mucho de tu configuración definida en el NodePool. Y no creo que una herramienta sea mejor que la otra en todos los casos: depende de tu infraestructura, y conviene medir antes y después, porque el ahorro no viene solo.

Un poco de contexto: Karpenter nació en AWS en 2021 como proyecto open source. En 2023 sus APIs pasaron a beta y la parte neutral del proyecto se donó a la CNCF, dentro de Kubernetes SIG Autoscaling. La versión 1.0, que estabiliza las APIs principales, salió en agosto de 2024.

Por dentro

El flujo es más o menos así: hay un pod sin asignar, Karpenter mira sus requests y restricciones, crea un NodeClaim, se lanza la instancia en EC2, el nodo se registra en el clúster y recién ahí el scheduler le asigna el pod, que pasa a Running.

Tambien hay que considerar que esto toma su tiempo, que la instancia ya exista no significa que esté lista, todavía tiene que arrancar y unirse al clúster.

Cómo elige la máquina

Karpenter no lanza un nodo por cada pod que llega. Primero espera alrededor de un segundo sin pods nuevos (hasta diez segundos como máximo) para juntarlos y decidir en lote. Después suma lo que piden en CPU, memoria y GPU, sin olvidarse de los DaemonSets ni de lo que reserva el sistema en cada nodo.

Con eso arma una lista de hasta 60 tipos de instancia que sirven, desde el más chico donde entra todo hasta otros más grandes, y se la pasa a EC2 Fleet para que lance una. En On-Demand se prioriza el precio más bajo y en Spot se combina el precio con el riesgo de interrupción.

Si EC2 no tiene capacidad de algún tipo en una zona, Karpenter lo descarta por un rato y sigue con los demás. Por eso, mientras más tipos de instancia permitas, más alternativas tiene. Limitarlo a una o dos familias puede parecer más seguro, pero en la práctica lo vuelve más frágil, sobre todo con Spot.

NodePool, EC2NodeClass y NodeClaim

Estos tres son los que más se confunden, así que les dediqué un buen rato en la charla.

El NodePool son las reglas: qué nodos puede crear Karpenter, con qué arquitecturas, categorías, si son Spot u On-Demand, los límites y cómo maneja la disrupción. La EC2NodeClass es la parte de AWS: la imagen, las subredes, los security groups y el rol de la instancia. Y el NodeClaim es la solicitud concreta de una máquina. Ese no lo escribes tú, lo crea Karpenter, y es lo primero que yo reviso cuando algo no funciona.

Un NodePool sencillo se ve así:

apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: general
spec:
  template:
    spec:
      nodeClassRef:                       # 1. enlaza con la EC2NodeClass
        group: karpenter.k8s.aws
        kind: EC2NodeClass
        name: default
      requirements:
        - key: kubernetes.io/arch         # 2. arquitectura permitida
          operator: In
          values: ["amd64"]
        - key: karpenter.sh/capacity-type # 3. solo On-Demand
          operator: In
          values: ["on-demand"]
        - key: karpenter.k8s.aws/instance-category # 4. cómputo, general, memoria
          operator: In
          values: ["c", "m", "r"]
  limits:
    cpu: "100"                            # 5. tope de capacidad del NodePool

Hay que encontrar un equilibrio: si restringes demasiado, Karpenter se queda sin opciones, y si abres mucho, toca validar bien qué tipos van a aparecer. Y el NodePool solo no alcanza, también necesitas la EC2NodeClass, los permisos y la red bien configurados.

Leer un NodeClaim

$ kubectl get nodeclaims
NAME            TYPE         CAPACITY    ZONE         NODE           READY
general-x7k2p   m6i.large    on-demand   us-east-1a   ip-10-0-1-23   True
general-b4m9t   c6i.xlarge   spot        us-east-1b   ip-10-0-2-87   True

Cada NodeClaim pasa por cuatro condiciones: Launched cuando EC2 aceptó la solicitud, Registered cuando el nodo se unió al clúster, Initialized cuando terminó de arrancar y quitó sus taints de inicio, y Ready cuando ya se le pueden asignar pods. Si un pod sigue en Pending, fíjate cuál de esas condiciones no llegó a True. Y si ni siquiera aparece un NodeClaim, el problema está antes: en el NodePool o en los requests del pod.

Si lo quieres instalar en EKS

Esto es lo que necesitas tener listo:

Los permisos de IAM: el rol del controlador (con EKS Pod Identity o IRSA) y el rol de los nodos.
La etiqueta karpenter.sh/discovery en las subredes y security groups que va a usar.
Una cola de interrupciones con SQS y EventBridge, para que reciba los avisos de Spot y de mantenimiento.
Un lugar donde correr el controlador que no sean los nodos que él mismo administra, por ejemplo un managed node group pequeño o Fargate.
Al menos un NodePool y una EC2NodeClass. Sin eso no crea ningún nodo.

helm upgrade --install karpenter oci://public.ecr.aws/karpenter/karpenter \
  --version "${KARPENTER_VERSION}" \
  --namespace kube-system \
  --set settings.clusterName=${CLUSTER_NAME} \
  --set settings.interruptionQueue=${CLUSTER_NAME}

Mi consejo es seguir la guía oficial de getting started para la versión exacta que vas a instalar, porque los detalles cambian entre versiones. De hecho es la misma guía que seguí para la Demo mostrada en la charla.

Los requests importan más de lo que parece

Karpenter decide qué máquina lanzar sumando los requests de los pods. Y ojo que request, uso real y límite no son lo mismo: el request es lo que reserva el scheduler, el uso real es lo que la app consume en ese momento y el límite es el tope.

Si pones requests muy altos, vas a terminar con nodos más grandes o más nodos de los que necesitas. Si los pones muy bajos, se te llenan los nodos de pods que después compiten por recursos cuando sube la carga. Karpenter trabaja con lo que declaras, no puede adivinar lo que tu aplicación necesita de verdad, así que ajustar los requests con métricas reales sigue siendo trabajo nuestro.

Consolidación

Karpenter no solo agrega capacidad, también la saca cuando sobra.

Si los pods de varios nodos con poco uso entran en menos nodos, los reacomoda y elimina los que quedan sobrando. Esto se configura en el NodePool:

spec:
  disruption:
    consolidationPolicy: WhenEmptyOrUnderutilized
    consolidateAfter: 5m

Con WhenEmptyOrUnderutilized retira los nodos vacíos y también los que están poco usados, siempre que sus pods entren en otro lado o en un nodo más barato. Ahorras más, pero se mueven más pods. Con WhenEmpty solo retira nodos que no tienen pods de aplicación (los DaemonSets no cuentan), así que ahorras menos pero no desaloja nada. Y consolidateAfter es cuánto espera desde que el último pod entró o salió del nodo antes de considerarlo, para no reaccionar a cada pico.

Antes de sacar un nodo, Karpenter verifica que los pods entren en lo que queda, respetando sus restricciones y sus PodDisruptionBudgets. Si recién estás empezando, yo arrancaría con WhenEmpty o con un consolidateAfter más largo, y vería cuántos pods se mueven antes de ponerlo más agresivo.

¿Spot u On-Demand?

On-Demand se paga a tarifa normal y es más predecible, aunque tampoco es infalible. Spot puede salir mucho más barato, pero no siempre hay disponibilidad y AWS puede recuperar la instancia avisándote con unos dos minutos de anticipación.

Antes de meter Spot, revisa que tengas varias réplicas, reintentos, el estado y los datos protegidos, muchos tipos de instancia permitidos, y que hayas probado una interrupción de verdad. Yo lo decidiría según qué tan crítica es la aplicación y cuánto riesgo estás dispuesto a aceptar, no solo por el precio por hora.

Cuando Karpenter retira nodos

Un nodo puede salir por consolidación, por drift (cuando ya no coincide con la configuración, por ejemplo porque hay una AMI nueva), porque llegó a su expireAfter o por una interrupción de Spot. Para protegerte hay algunas herramientas, aunque cada una tiene su alcance.

El PodDisruptionBudget va en tu aplicación:

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: web-pdb
spec:
  minAvailable: 2
  selector:
    matchLabels:
      app: web

Los disruption budgets van en el NodePool y controlan cuántos nodos se pueden retirar a la vez y en qué horario:

spec:
  disruption:
    budgets:
      - nodes: "10%"                    # como máximo 10 % de los nodos a la vez
      - nodes: "0"                      # ninguno en este horario...
        schedule: "0 9 * * mon-fri"     # ...de lunes a viernes desde las 9:00
        duration: 8h                    # durante 8 horas

Y si hay un pod (o un nodo) que no quieres que Karpenter toque, puedes usar esta anotación:

metadata:
  annotations:
    karpenter.sh/do-not-disrupt: "true"

Cuidado con el PDB: si lo haces muy estricto, por ejemplo con minAvailable igual al número de réplicas, puede bloquear la consolidación indefinidamente. Y ninguna de estas protecciones te salva de una interrupción de Spot o de una falla, así que la aplicación igual tiene que aguantar perder un nodo.

La pregunta que le dejé al público fue: ¿qué impacto tiene esa acción en mi aplicación, y cómo compruebo que se recupera?

Para cerrar

Si me quedo con algo de esta charla es que Karpenter consigue capacidad según lo que realmente piden tus pods y la devuelve cuando ya no hace falta, que entender bien la diferencia entre NodePool, EC2NodeClass y NodeClaim te ahorra mucho tiempo al depurar, y que bajar costos nunca debería ir en contra de la disponibilidad.

¿Vale la pena usarlo? Si tus cargas cambian bastante, si necesitas muchos tipos de instancia o si mantener grupos de nodos ya se volvió un dolor de cabeza, probablemente sí. Pero úsalo porque resuelve un problema que puedes medir, no porque esté de moda.

Gracias a Platform Engineering Perú por la invitación y por organizar KubeFest #3, y a todos los que fueron y se quedaron a preguntar.

Aquí les dejo los slides de la presentación: https://speakerdeck.com/bnktch13/karpenter-en-el-mundo-cloud-native

Referencias

EKS Auto Mode: correr Kubernetes sin andar peleando con los nodos

Bianca Torres — Fri, 04 Sep 2026 18:54:26 +0000

Si algo aprendí gestionando EKS en producción, es que mantener los nodos se lleva más tiempo del que uno imagina. Managed node groups, Karpenter, el EBS CSI driver, actualizar AMIs, y el clásico "¿por qué este pod lleva 10 minutos en Pending?" a la hora menos pensada. No es lo más entretenido del rol, pero es parte de lo que nos toca hacer para mantener un cluster sano en producción.

Por eso, cuando probé EKS Auto Mode, me hice esta pregunta: "si dejo que AWS haga todo esto por mí, ¿qué gano y qué pierdo?". Este artículo es esa respuesta, con un laboratorio que puedes seguir tú mismo en menos de 30 minutos.

Mantener nodos es casi un segundo trabajo

Antes de vender la solución, hablemos del problema de verdad. En un EKS "clásico", tú te encargas de un montón de cosas:

Crear y dimensionar los node groups. ¿m5.large? ¿c6i.xlarge? ¿Spot u On-Demand? Cada decisión te la cobra el futuro.
Instalar y afinar un autoscaler. Cluster Autoscaler o Karpenter. Los dos piden configuración, permisos IAM y mantenimiento.
Cuidar los add-ons. CoreDNS, kube-proxy, EBS CSI, VPC CNI... instalarlos, versionarlos, actualizarlos.
Parchear las AMIs. Cada vez que aparece una vulnerabilidad de seguridad en el sistema operativo del nodo (CVE), es nuestro trabajo subsanarlo.
Debuggear el scheduling. Ese 0/3 nodes are available: Insufficient memory que aparece justo cuando ya te ibas a desconectar.

Lo irónico es que nada de eso hace tu producto mejor. Es puro "impuesto de plataforma". Trabajo que haces para que Kubernetes exista, no para que tu app sea mejor.

Entonces, ¿Qué es EKS Auto Mode?

AWS se hace cargo del cómputo, el almacenamiento y el networking del cluster por ti. Por dentro usa Karpenter y nodos con Bottlerocket, pero todo eso queda tras bambalinas. Tú ya no administras node groups ni instalas add-ons uno por uno.

Tú declaras tus apps, AWS decide y levanta la infraestructura para correrlas. Los nodos aparecen cuando tus pods los necesitan, y se van cuando ya no.

Lab: de cero a app corriendo, con nodos que aparecen solos

Lo que necesitas:

AWS CLI v2 configurado (aws configure)
eksctl v0.195.0 o más
kubectl
Permisos IAM sobre EC2, EKS, IAM y VPC

Paso 1: Crear el cluster con Auto Mode

eksctl create cluster \
  --name demo-automode \
  --region us-east-1 \
  --enable-auto-mode

Ese único comando te crea el cluster, la VPC, las subredes, activa Auto Mode y deja los add-ons esenciales gestionados por AWS. Tarda aproximadamente unos 15 minutos.

Paso 2: Mirar el cluster recién creado

kubectl get nodes

kubectl get nodepools

Auto Mode crea dos node pools automáticamente:

system arranca con 1 nodo desde el inicio. Ese nodo corre los componentes internos del propio cluster (CoreDNS y los add-ons gestionados). Por eso kubectl get nodes sí te muestra un nodo apenas creas el cluster.
general-purpose arranca con 0 nodos. Este es el pool donde van a caer tus aplicaciones, y ahí es donde se ve la magia: se queda vacío hasta que despliegas algo que necesite cómputo.

Así que el cambio de chip es este: ver el pool de tus cargas en cero no significa que algo se rompió. Significa que todavía no hay nada tuyo que correr, y AWS no está cobrándote nodos de más.

Paso 3: Desplegar una app

# nginx-demo.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-demo
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx-demo
  template:
    metadata:
      labels:
        app: nginx-demo
    spec:
      containers:
      - name: nginx
        image: nginx:latest
        resources:
          requests:
            cpu: "250m"
            memory: "128Mi"
---
apiVersion: v1
kind: Service
metadata:
  name: nginx-demo
spec:
  type: LoadBalancer
  selector:
    app: nginx-demo
  ports:
  - port: 80
    targetPort: 80

kubectl apply -f nginx-demo.yaml

Paso 4: Ver Auto Mode en acción

kubectl get nodes

En unos 30 segundos vas a ver aparecer un nodo nuevo en el pool general-purpose (ese que estaba en cero) sin que tú lo hayas pedido. AWS se dio cuenta de que tus pods necesitan cómputo y levantó una instancia EC2 solo.

Paso 5: Escalar y mirar qué pasa

kubectl scale deployment nginx-demo --replicas=10
kubectl get nodes

Al escalar en numero de replicas de nuestra app, tener un solo nodo será insuficiente. Si la capacidad de ahora no alcanza, Auto Mode levanta más. No tocaste ningún autoscaler, no editaste ningún node group.

Paso 6: Destruir

eksctl delete cluster --name demo-automode --region us-east-1

Es super importante que al finalizar nuestro laboratorio destruymos todos los recursos creado, para evitar costos innecesarios. Un cluster olvidado es una sorpresa fea en la factura.

Clásico vs Auto Mode

Qué	EKS clásico	EKS Auto Mode
Gestión de nodos	Manual / tu propio Karpenter	AWS
Add-ons (CoreDNS, CSI, etc.)	Los instalas y versionas tú	Gestionados
Actualizar AMIs	Lo gestionas tú	AWS
Autoscaling	Configuras CA o Karpenter	Automático
Tu tiempo operando	Mucho	Poco
Personalización	Total	Acotada
Curva de arranque	Empinada	Suave

Cuándo usarlo y cuándo no (Según mi opinión)

Úsalo si:

Arrancas un cluster nuevo y quieres velocidad sin construir toda una plataforma.
Tu equipo es chico y no quieres tener a alguien dedicado a cuidar nodos.
Tus workloads son bastante estándar: APIs, workers, web.

Piénsalo dos veces si:

Dependes de configuraciones muy específicas de nodo (kernels custom, DaemonSets exigentes, GPUs con drivers a medida).
Ya tienes un Karpenter afinado que te ahorra dinero y no lo quieres soltar.
Necesitas control total del ciclo de vida de la AMI por temas de compliance.

Auto Mode te cambia control por simplicidad. Ganas horas de operación, cedes algunos grados de personalización. Para la mayoría, ese cambio vale muchísimo la pena. Para casos muy puntuales, todavía no.

¿Y cuánto me va a costar?

Auto Mode suma un pequeño cargo de gestión encima del costo del EC2 que corre por debajo. Pero no te quedes solo con "cuánto cuesta el add-on". La cuenta real es: cuánto cuesta el add-on menos las horas de ingeniería que dejas de gastar cuidando nodos, autoscalers y parches. Cuando sumas ese tiempo, el número se ve muy distinto.

En conclusión

EKS Auto Mode no es magia. Es AWS haciendo el trabajo de plataforma que muchos veníamos haciendo a mano. Si gestionas clusters en producción, pruébalo con un workload que no sea crítico y mide cuánto tiempo dejas de invertir en cosas que no hacen mejor tu producto.

Nunca más hardcodees un token: Seguridad en GitHub para DevOps

Bianca Torres — Wed, 10 Jun 2026 21:41:47 +0000

El pasado sábado 6 de junio tuve la oportunidad de participar como speaker en el GitHub Community Day Perú 2026, donde compartí una charla sobre un tema que sigue siendo una de las causas más frecuentes de incidentes de seguridad: la exposición accidental de credenciales.

Durante la sesión hablamos de herramientas gratuitas que muchos equipos ya tienen disponibles dentro de GitHub, pero que no siempre aprovechan al máximo. Usamos GitHub todos los días para gestionar código, colaborar con nuestros equipos y automatizar despliegues, pero en muchas ocasiones solo utilizamos una pequeña parte de todo lo que la plataforma nos ofrece.

La buena noticia es que GitHub incorpora múltiples funcionalidades de seguridad que pueden ayudarnos a prevenir filtraciones de credenciales, proteger nuestros pipelines y mejorar nuestra postura de seguridad sin necesidad de adquirir herramientas adicionales.

En este artículo recopilo los principales conceptos que vimos durante la charla, junto con una demostración práctica de cómo desplegar una aplicación en AWS sin almacenar una sola credencial permanente.

El problema

Todos lo hemos hecho.

Hardcodear un API key “solo por ahora”, pushear un .env por accidente o compartir un token por Slack para salir de un apuro.

Son errores comunes, pero las consecuencias pueden ser graves: desde una factura inesperada en AWS hasta una filtración de información sensible.

En 2025, De acuerdo al reporte de GitGuardian, GitHub detectó más de 28 millones de secretos expuestos en repositorios públicos. Access Keys de AWS, tokens de GitHub, webhooks de Slack y muchas otras credenciales quedaron visibles para cualquiera que quisiera utilizarlas.

El flujo típico suele verse así:

Un developer necesita desplegar una aplicación.
Crea una Access Key y Secret Key.
Las almacena en un archivo .env o directamente en el código.
El archivo termina llegando al repositorio.
Un bot detecta las credenciales y comienza a utilizarlas en cuestión de segundos.

La solución no es simplemente “tener más cuidado”.
La solución es construir mecanismos que hagan mucho más difícil que estos errores lleguen a producción.

GitHub nos ofrece varias capas de protección que pueden ayudarnos precisamente con eso.

Las 5 capas de Seguridad en Github

1. GitHub Secrets

La primera línea de defensa es evitar almacenar información sensible dentro del código.

GitHub Secrets permite guardar valores cifrados que pueden ser consumidos por GitHub Actions durante la ejecución de un workflow.

Características:

Encriptados mediante libsodium.
Ocultos automáticamente en los logs.
No pueden visualizarse nuevamente después de guardarse.
Disponibles a nivel de repositorio, environment u organización.

Además, los Environments agregan controles adicionales como:

Aprobaciones manuales para producción.
Restricciones por branch.
Wait timers.
Protección de despliegues críticos.

Si todavía tienes credenciales hardcodeadas en tu código, este debería ser el primer cambio que realices.

2. OIDC con AWS (Zero Credentials)

OIDC es un protocolo de autenticación que permite que dos servicios se reconozcan sin compartir credenciales.

Tradicionalmente, muchos pipelines almacenan Access Keys de AWS dentro de GitHub Secrets.
Aunque esto es mejor que hardcodearlas, seguimos dependiendo de credenciales permanentes que pueden ser filtradas o comprometidas.

Con OpenID Connect (OIDC) podemos eliminar completamente ese problema.

¿Cómo funciona?

GitHub Actions inicia la ejecución del workflow.
GitHub genera un token JWT temporal.
AWS valida el token mediante un OIDC Provider.
AWS verifica que el repositorio tenga permiso para asumir un rol específico.
AWS entrega credenciales temporales.
Las credenciales expiran automáticamente

No hay keys. No hay tokens permanentes. Nada que pueda leakearse.

Paso 1 — Crear el OIDC Provider en IAM:
Provider URL: token.actions.githubusercontent.com

Paso 2 — Crear un IAM Role con trust policy:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Federated": "arn:aws:iam::ACCOUNT_ID:oidc-provider/token.actions.githubusercontent.com"
      },
      "Action": "sts:AssumeRoleWithWebIdentity",
      "Condition": {
        "StringEquals": {
          "token.actions.githubusercontent.com:aud": "sts.amazonaws.com"
        },
        "StringLike": {
          "token.actions.githubusercontent.com:sub": "repo:MI-ORG/MI-REPO:*"
        }
      }
    }
  ]
}

La condición StringLike es clave: solo TU repo puede asumir este rol. Si alguien forkea tu repo, no puede deployar.

Paso 3 — Usar en el workflow de Github Actions:

permissions:
  id-token: write
  contents: read

steps:
  - uses: aws-actions/configure-aws-credentials@v4
    with:
      role-to-assume: ${{ vars.AWS_ROLE_ARN }}
      aws-region: us-east-1

Eso es todo. Cero secrets de AWS en GitHub.

3. Secret Scanning

Incluso con buenas prácticas, los errores siguen ocurriendo.

Por eso GitHub incorpora Secret Scanning.
Esta funcionalidad analiza automáticamente los commits buscando patrones asociados a credenciales conocidas.

Actualmente puede detectar más de 200 tipos de secretos pertenecientes a más de 100 proveedores.
Ejemplo: AWS, GitHub, Slack, Stripe, Twilio, npm, etc.

Para habilitarlo:
Settings → Code security and analysis → Secret scanning → Enable

Cuando GitHub detecta una credencial:

Genera una alerta.
Muestra exactamente dónde se encuentra.
En algunos casos coordina la revocación automática con el proveedor.

Es una capa reactiva, pero extremadamente útil.

4. Push Protection

Mientras Secret Scanning detecta problemas después del commit, Push Protection intenta detenerlos antes.

Cuando GitHub detecta una credencial durante un push, simplemente bloquea la operación.

El secret nunca llegó al repo. Nunca se expuso. Protección proactiva.

Para habilitarlo:
Settings → Code security and analysis → Push protection → Enable

5. Dependabot

La seguridad no se limita únicamente a las credenciales.
Muchas vulnerabilidades provienen de dependencias desactualizadas.

Cuando se publica un CVE crítico que afecta una librería utilizada por nuestro proyecto, Dependabot puede:

Detectar la vulnerabilidad.
Generar una alerta.
Crear automáticamente un Pull Request con la actualización.

Configuración (.github/dependabot.yml):

version: 2
updates:
  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "weekly"
      day: "monday"

  - package-ecosystem: "github-actions"
    directory: "/"
    schedule:
      interval: "weekly"

Además de dependencias de aplicación, Dependabot también ayuda a mantener actualizadas las GitHub Actions utilizadas por nuestros pipelines.

Demo: Deploy completo sin credenciales

Para demostrar cómo funcionan varias de estas capas trabajando juntas, preparé una aplicación sencilla que lee un secreto desde una variable de entorno y lo muestra en una página web.

El código relevante:

const SECRET_MESSAGE = process.env.SECRET_MESSAGE || 'No secret configured'

La aplicación no conoce el valor del secreto.
Simplemente espera encontrar una variable de entorno durante la ejecución.

La demostración consistió en desplegar esta aplicación en Amazon ECS Fargate, utilizando GitHub Actions para automatizar todo el proceso y OIDC para autenticarnos en AWS sin necesidad de almacenar Access Keys permanentes.

El flujo:

GitHub Secret (SECRET_MESSAGE)
       ↓
GitHub Actions (OIDC → sin AWS keys)
       ↓
Build Docker image → Push a ECR
       ↓
Update ECS Task Definition (inyecta el secret)
       ↓
Deploy a ECS Fargate
       ↓
App muestra el secret

Resultado: El secret se muestra en la app, pero si buscas en todo el repositorio, no lo vas a encontrar. Se inyecta en runtime a través de la Task Definition de ECS. Nunca existió en el código fuente.

Qué puedes hacer hoy

Si te llevas algo de este artículo, que sea esto:

Habilita Push Protection: Protección inmediata contra leaks accidentales.
Migra de AWS access keys a OIDC: Eliminas el riesgo más grande de tu pipeline.
Agrega dependabot.yml: Un archivo y tus dependencias se mantienen actualizadas automáticamente.
Mueve secrets hardcodeados a GitHub Secrets: Revisa tu código, busca tokens hardcodeados, y muévelos.

Conclusión

La seguridad de credenciales no tiene que ser complicada.

GitHub nos proporciona múltiples capas de protección que abarcan desde la prevención de errores humanos mediante Push Protection, hasta la detección de credenciales expuestas con Secret Scanning y la eliminación completa de credenciales permanentes mediante OIDC.

La principal reflexión que quise transmitir durante mi charla en el GitHub Community Day Perú 2026 es que muchas veces utilizamos GitHub todos los días, pero no aprovechamos todo el potencial que nos ofrece en materia de seguridad.

Con unas pocas configuraciones podemos reducir significativamente el riesgo de exposición de credenciales y fortalecer nuestros pipelines sin añadir complejidad innecesaria.

Las diapositivas utilizadas para la presentación están disponibles en: https://speakerdeck.com/bnktch13/seguridad-en-github-para-devops
Y el código completo del ejemplo utilizado durante la demostración está disponible en: https://github.com/BnkTCh/secure-deploy-demo

Te invito a explorarlo, probarlo y adaptarlo a tus propios proyectos.

Y si estuviste presente en la charla durante el GitHub Community Day Perú 2026, gracias por acompañarme y por todas las preguntas y conversaciones que hicieron la sesión aún más interesante.

Prompts que construyen: cómo dominar Amazon Q Developer en tu día a día

Bianca Torres — Mon, 05 Jan 2026 02:22:14 +0000

¿Sabías que el 40% del tiempo de un desarrollador se va en tareas repetitivas como leer documentación, generar boilerplate y debuggear errores?

Como DevOps Engineer, he descubierto que Amazon Q Developer puede transformar estas tareas tediosas en procesos eficientes. No es solo "otra IA más": es un asistente especializado que entiende el ecosistema AWS.

En este artículo te muestro cómo usarlo de forma práctica y, más importante, cómo escribir prompts que generen resultados reales, no respuestas genéricas.

Este artículo está basado en una charla que di sobre Amazon Q Developer y Prompt Engineering.

Si prefieres el formato video, aquí puedes verla completa:
https://www.youtube.com/live/M3sr0p8G5OU?si=YI9GLC-6PN8ygRql

¿Qué es Amazon Q Developer?

Amazon Q Developer es un asistente de IA generativa enfocado en:

Desarrollo de software
Administración de AWS
Mejores prácticas oficiales

Se integra directamente en:

IDEs como VS Code
AWS Console
CLI

A diferencia de otras herramientas genéricas, Amazon Q está entrenado con:

Documentación oficial de AWS
Ejemplos reales
Buenas prácticas del ecosistema cloud

¿Cómo funciona Amazon Q Developer?

Amazon Q Developer funciona sobre Amazon Bedrock, utilizando distintos Large Language Models (LLMs), entre ellos:

Amazon Titan
GPT (y otros modelos disponibles)

Algunos puntos clave:

No usa un único modelo fijo
Cuanto más popular es un lenguaje o framework, mejor entrenado estará el modelo.
Más datos de entrenamiento → mejores sugerencias

Por eso, tecnologías comunes como Terraform, Kubernetes o Python suelen tener respuestas de muy buena calidad.

¿Qué podemos hacer con Amazon Q Developer?

En el día a día, Amazon Q puede ayudarte a:

Autocompletar código más rápido
Obtener soluciones simples sin salir del IDE
Explicar y documentar código
Explicar mensajes de error
Generar pruebas
Crear código base (boilerplate)
Mejorar tu productividad en general

La clave no es solo qué hace, sino cómo se lo pides.

Casos de uso reales donde Amazon Q brilla

Para DevOps Engineers:

Infraestructura como código: Generar templates de CloudFormation/Terraform
Troubleshooting: Interpretar logs de CloudWatch y errores de servicios AWS
Automatización: Crear scripts de CI/CD y pipelines

Para Developers:

SDK de AWS: Generar código para interactuar con servicios AWS
Serverless: Crear funciones Lambda con mejores prácticas
Containerización: Dockerfiles optimizados para ECS/EKS

Para Cloud Architects:

Diseño de arquitecturas: Sugerir patrones y servicios apropiados
Optimización de costos: Identificar oportunidades de ahorro
Seguridad: Implementar controles y políticas IAM

¿Qué es un prompt?

Un prompt es simplemente:
La instrucción que le das a la IA para que realice una tarea.
Pero la diferencia entre frustración y productividad está en la calidad del prompt.

Prompt vago vs Prompt bueno

Prompt vago:

Explícame este error

Prompt bueno:

Explícame este error que ocurre en un pod de Kubernetes en EKS cuando intento 
desplegar una aplicación Spring Boot en Java 17 y el pod entra en estado 
CrashLoopBackOff.

👉 El contexto lo es todo.

Buenas prácticas de Prompt Engineering

La regla de las 4 C:

Estas son las prácticas que mejor resultado me han dado usando Amazon Q Developer:

Claro
Sé específico sobre lo que quieres.
Contexto
Incluye información clave como:
Lenguaje
Versión
Servicio
Entorno
Conciso
Evita el ruido innecesario.
Continuo
Itera. Ajusta el prompt según la respuesta que recibes.

Checklist antes de enviar un prompt

Antes de presionar Enter, pregúntate:

¿Qué quiero exactamente? (tarea + resultado esperado)
¿Dónde corre? (lenguaje, versión, servicio, entorno)
¿Es claro y corto?
¿Qué siguiente paso pediré si no es perfecto?

Prompt engineering es un diálogo, no una orden única.

Conclusión
Amazon Q Developer puede ahorrarte mucho tiempo si sabes cómo hablarle.

No se trata de escribir prompts "bonitos", sino prompts útiles, con intención clara, contexto técnico y capacidad de iteración.

Si eres DevOps Engineer, Cloud Engineer o Developer y trabajas con AWS, aprender a usar Amazon Q Developer bien es una ventaja real, no solo hype.

Próximos pasos:

Instala Amazon Q Developer en tu IDE favorito:
https://docs.aws.amazon.com/es_es/amazonq/latest/qdeveloper-ug/q-in-IDE-setup.html
Practica con un proyecto real - empieza con tareas simples
Documenta tus prompts exitosos - crea tu propia biblioteca
Comparte con tu equipo - la productividad se multiplica

¿Y tú?
¿Ya usas Amazon Q Developer en tu día a día?