ContacteÚs de Clients Kafka a EventHub (Permisos i ACLs)
Navegació
| ⬅️ Ús de Schemes | ➡️ Seguretat a EventHub |
|---|
Ús de Clients Kafka a EventHub (Permisos i ACLs)
Canigó – Guia per a aplicacions
Aquesta pàgina explica què ha de fer una aplicació per sol·licitar i gestionar un Client Kafka (identitat i permisos) a EventHub.
No descriu el govern en detall: indica els passos pràctics i els artefactes a utilitzar.
1. Quan necessites un Client Kafka?
Necessites un Client Kafka si:
- Produiràs esdeveniments en un topic.
- Consumiràs esdeveniments des d’un topic.
- Utilitzaràs Stream Processing o Connectors.
❌ No reutilitzis un client Kafka per a:
- Múltiples aplicacions diferents.
- Diferents entorns (INT / PRE / PRO).
- Usos amb permisos més amplis dels necessaris.
2. Alta d’un Client Kafka: què has de fer
Pas 1. Omplir la plantilla de sol·licitud (obligatori)
- Plantilla oficial: Plantillas_Solicitud_EventHub
- Primer, omplir la pestanya Datos_Proyecto (si no s’ha fet ja).
- Després, una fila per client a la pestanya Solicitud_ClienteKafka.
- Una fila per combinació client + plataforma/cluster. Si el client opera en vàries plataformes (Onpremise + Azure), cal una fila per cada una.
Camps que ha d’omplir l’aplicació:
| Camp | Descripció |
|---|---|
| Owner_Soporte | Equip de suport de l’aplicació |
| Identificador_Corto | Nom curt del client (ex: crm, fact) — es combina amb el codi per generar el nom |
| Plataforma_Cluster | On necessita permisos: Onpremise / Azure / AWS / GCP |
| Criticidad_Cliente | Alta / Media / Baja |
| Topics_Asociados | Topics que usarà el client (context funcional, no restricció de permisos) |
Camps automàtics (no modificar):
| Camp | Origen |
|---|---|
| Codigo_Aplicacion, Nombre_Aplicacion, JIRA_ID, Owner_Tecnico | Heredats de Datos_Proyecto |
| Nombre_Cliente_Generado | Fórmula: {codigo}-{identificador_corto} (ex: a1234-crm) |
Nota important: El nom del client Kafka és el mateix en els 3 entorns (INT / PRE / PRO). No s’afegeix sufix d’entorn. L’autenticació és sempre OAuth (no es sol·licita). Els permisos base (prefix de topics i consumer group) es deriven automàticament del nom del client.
Sense la fitxa correctament omplerta no es valida la sol·licitud.
Pas 2. Obrir la sol·licitud
- Crear tiquet JIRA ACOEVENT.
- Adjuntar la fitxa omplerta.
Pas 3. Validació
L’Oficina EventHub valida:
- Naming del client (generat automàticament).
- Coherència de la plataforma sol·licitada.
- Abast dels permisos derivats.
- Compliment del principi de mínim privilegi.
Resultat:
- ✅ Aprovat → es creen credencials i permisos.
- 🔄 Retornat → cal ajustar la fitxa.
Pas 4. Creació del client i permisos
- Es crea el Client Kafka a l’entorn corresponent.
- S’apliquen les RBAC validades.
- Es lliuren les credencials segons el model de seguretat vigent.
3. Què decideix la plataforma (no l’aplicació)
La plataforma defineix:
- Permisos efectius (RBAC) derivats del nom del client.
- Mecanisme d’autenticació (sempre OAuth).
- Permisos especials (si es sol·liciten i es justifiquen).
- Necessitat de CRQ en PRE o PRO.
4. Model de permisos (resum pràctic)
Principis clau:
- Mínim privilegi.
- Permisos explícits per recurs.
- Separació estricta per entorn.
Permisos habituals derivats del nom del client:
- WRITE sobre topics amb prefix del client.
- READ sobre topics amb prefix del client.
- READ sobre consumer groups amb prefix del client.
Aïllament per entorn: La separació entre INT, PRE i PRO és física — cada entorn té el seu propi clúster Kafka independent. Un client donat d’alta a INT únicament pot accedir als topics del clúster INT; no pot llegir ni escriure topics de PRE ni de PRO. No és possible accedir a topics d’un entorn diferent del clúster on el client està registrat.
Permisos addicionals o creuats:
- Han de sol·licitar‑se explícitament a la pestanya Permisos_Cross de la plantilla.
- Requereixen justificació, validació i coordinació amb el projecte propietari del topic.
5. Canvis sobre un Client Kafka
Es consideren canvis:
- Operar en una nova plataforma/cluster.
- Sol·licitar permisos addicionals o creuats.
- Canviar la criticitat.
Què cal fer:
- Actualitzar la fitxa.
- Obrir tiquet JIRA.
- Tramitar CRQ si aplica (obligatòria en PRO).
6. Baixa d’un Client Kafka
- Confirmació formal de no ús.
- Anàlisi d’impacte.
- Revocació de permisos.
- Eliminació del client Kafka.
En PRO:
- Requereix CRQ quan apliqui.
7. Errors habituals (evita’ls)
- Reutilitzar clients Kafka entre aplicacions.
- Sol·licitar permisos amplis “per si de cas”.
- Utilitzar el mateix client en diversos entorns.
- No indicar la plataforma/cluster correcta.
- Oblidar donar de baixa clients en desús.
8. Documentació de referència
I ara què?
Un cop entès l’ús funcional d’aquest element d’EventHub, els següents passos habituals són:
- Verificar que compleix els criteris i estàndards definits per la plataforma.
- Gestionar l’alta o modificació mitjançant l’autoservei governat, un cop validada la integració per l’Oficina EventHub.
- Preparar el canvi o desplegament segons l’entorn (INT / PRE / PRO), obrint la CRQ quan correspongui.