1. Clasificar lo que describe el cálculo y lo que da un acceso
Empieza por la información que tu programa consume realmente. El tamaño de lote, el nombre del modelo y el modo de procesamiento describen una experiencia. Un token que autoriza una descarga o una clave que abre un almacenamiento otorgan un acceso. El primer conjunto debe ser explicable; el segundo debe permanecer disponible solo donde sea necesario.
La frontera no se reduce a los nombres de variables. Una ruta puede revelar un cliente, una URL puede incluir un identificador y una pequeña muestra de datos puede ser confidencial. Evalúa, por tanto, también el contenido de los parámetros compartibles. Publicar la configuración y publicar todas sus rutas absolutas no son la misma decisión.
La tabla propone una clasificación de trabajo. No describe los servicios instalados en una máquina Kernodeck. Define para tu proyecto quién puede leer cada elemento, en qué momento y en qué copia; no dejes esa decisión al último export de un notebook.
Desplaza la tabla para leer todas las columnas.| Elemento | Rol | Tratamiento propuesto |
|---|---|---|
| Tamaño de lote, modo, umbral | Parámetros del cálculo | Versionar y validar sus valores. |
| Token, clave privada, contraseña | Medios de acceso | Proporcionar por separado y no incluir en las salidas. |
| Ruta, URL, identificador de corpus | Contexto potencialmente sensible | Verificar antes de compartir; preferir un identificador lógico. |
| Resultados y registros | Pruebas de ejecución | Elegir los campos conservados y controlar la carpeta transmitida. |
2. Elegir una única regla de prioridad
Un parámetro presente en el código, un archivo y una opción de lanzamiento se vuelve ambiguo si nadie sabe cuál gana. Fija una regla simple, por ejemplo: valores predeterminados documentados, luego archivo de configuración y luego opciones públicas del comando. Es un contrato de tu aplicación, no una prioridad universal proporcionada por Python.
Valida después de esta resolución. Rechaza una clave desconocida para que un error como batch_szie no se sustituya silenciosamente por un valor predeterminado. Distingue un entero, una cadena que representa un entero y un booleano. Añade después las restricciones útiles: valor positivo, modo permitido, combinación de parámetros coherente.
Por último, registra una configuración efectiva limitada a los campos permitidos. Explica lo que el programa utilizó, incluso cuando una opción sustituyó al archivo. No obtengas este documento serializando todo el objeto de configuración antes de quitarle algunas contraseñas conocidas: elige primero qué puede figurar en él.
3. Trabajar un ejemplo sin conectar ningún servicio
El siguiente ejemplo es didáctico y no se ejecuta. Describe una operación ficticia de producción de vectores con un lote de ocho elementos. La palabra embedding es aquí una elección de interfaz; no se carga ningún modelo y no se supone instalada ninguna dependencia de GPU. No se necesita ningún secreto para leer o validar este archivo.
El módulo estándar tomllib, disponible a partir de Python 3.11, lee el formato TOML. Transforma los valores del documento en objetos Python; no decide que un lote de cero esté prohibido en tu aplicación. El control de dominio sigue siendo explícito después de la lectura.
Este fragmento acepta exactamente dos claves y dos modos. Para usarlo en un proyecto, conecta después los argumentos, la gestión de errores y las rutas de salida. Los rechazos esperados son fáciles de razonar: batch_size a cero, batch_size en forma de cadena o la adición de una clave token. Son casos que debes verificar por tu cuenta, no resultados medidos aquí.
batch_size = 8
mode = "embedding"import tomllib
with open("config.toml", "rb") as source:
config = tomllib.load(source)
if set(config) != {"batch_size", "mode"}:
raise ValueError("CONFIG_KEYS")
if type(config["batch_size"]) is not int or config["batch_size"] <= 0:
raise ValueError("CONFIG_BATCH_SIZE")
if config["mode"] not in ("embedding", "classification"):
raise ValueError("CONFIG_MODE")
public_config = {
"batch_size": config["batch_size"],
"mode": config["mode"],
}4. Proporcionar el secreto solo a la etapa que lo necesita
Un paso que trabaja sobre un archivo ya presente no debe exigir un token de descarga. Solicita el secreto en la frontera donde el acceso se vuelve necesario. Si ese paso está activado pero le falta su acceso, detenlo con un mensaje que indique el canal esperado, sin mostrar el valor recibido ni copiar toda la solicitud.
El canal depende del entorno disponible: gestor de secretos, archivo de credenciales de acceso restringido o mecanismo de inyección previsto por tu organización. Una variable de entorno puede servir como interfaz, pero sigue siendo un dato accesible al proceso y susceptible de aparecer en diagnósticos. No confundas comodidad de inyección con protección completa.
Limita el acceso al perímetro útil y prevé su reemplazo. Una solicitud de preparación de software no garantiza la presencia de un gestor de secretos. Verifica el mecanismo realmente disponible antes de construir tu lanzamiento en torno a él, y luego evita transmitir el secreto a subprocesos que no lo necesitan.
5. Diseñar un registro útil sin copiar la entrada
Define algunos eventos: configuración aceptada, archivo verificado, partición completada, salida validada. Asígnales un identificador de ejecución, un paso y un contador. Un error CONFIG_BATCH_SIZE basta para localizar la regla en cuestión; no necesita contener el archivo completo.
OWASP recomienda excluir de los registros, en particular, contraseñas, tokens de acceso y claves. Aplica esta regla también a las excepciones, a los objetos mostrados para depurar y a las salidas de celdas. Un enmascaramiento aplicado en la última pantalla no elimina lo que ya se escribió en un archivo o en una captura.
Para compartir un incidente, prepara una pequeña selección: versiones útiles, parámetros autorizados, error y un ejemplo sintético que reproduzca el problema. Evita el archivado automático de toda la carpeta. Revisa también las URL, los encabezados, las rutas y las líneas cercanas al error; un mensaje aparentemente inofensivo puede estar rodeado de datos sensibles.
6. Verificar la separación antes de compartir
Prepara tres pruebas: configuración válida sin paso remoto, configuración inválida y paso que exige un acceso ausente. La primera debe poder llegar hasta su frontera funcional sin secretos innecesarios; las otras dos deben dar errores distintos. Verifica también que una modificación pública del tamaño de lote aparezca en la configuración efectiva.
Para controlar tu procedimiento de uso compartido, utiliza una cadena centinela manifiestamente ficticia y sin poder de acceso. Hazla pasar por el mismo lugar que un secreto durante un ejercicio aislado y luego búscala en los registros, las exportaciones y los archivos seleccionados. Su ausencia es un control limitado de ese recorrido, no una prueba de que todas las filtraciones sean imposibles.
Añade los archivos privados correspondientes a tus exclusiones de Git, pero verifica también los archivos ya rastreados. La documentación de Git precisa que gitignore afecta a los archivos no rastreados; añadir un patrón no elimina un secreto ya registrado. Examina lo que vas a transmitir, no solo las reglas que se supone que lo excluyen.
7. Reaccionar ante una difusión y conservar un rastro aprovechable
Si un acceso quedó expuesto, deja de reutilizarlo y haz que se revoque o se reemplace ante el sistema que lo emitió. Eliminar una línea del archivo actual no vuelve inofensivas las copias anteriores. Identifica los lugares afectados para retirar lo que sea posible y comprender el alcance de la difusión.
Tu carpeta reproducible puede conservar después el nombre del canal utilizado y los parámetros autorizados, sin conservar el secreto en sí. Un lanzamiento futuro solicitará un acceso válido en el momento adecuado. Obtienes así un procedimiento transmisible sin convertir el archivo del experimento en un llavero de accesos.
Este método se refiere a tu aplicación y a sus entregables. No garantiza ni el aislamiento de todo el entorno ni la ausencia de rastros técnicos en otros lugares. Para pasar a la ejecución, combínalo con un entorno documentado, datos controlados y un seguimiento que distinga el progreso del resultado validado.