Deadshot es un escáner de solicitudes de extracción que busca la introducción de secretos a través de relaciones públicas al comparar cada línea de diferencias con un conjunto de expresiones secretas conocidas.
El servicio es responsable de:
El servicio NO:
Deadshot es una aplicación multicontenedor Flask-Celery-Redis que se instala como una aplicación Github para ejecutarse en cada solicitud de extracción creada en la rama principal de un repositorio en el que está instalada la aplicación Github.
El contenedor Flask es el punto de entrada para el servicio al exponer las rutas API definidas en blueprints.py. Una vez que se recibe una carga útil de solicitud de extracción en la ruta API, el servicio reenvía la carga útil a una cola de Redis para que el contenedor Celery la recoja y escanee la diferencia de la solicitud de extracción. Después de que el contenedor de apio busca expresiones regulares secretas específicas, comenta las relaciones públicas, Slack notifica al canal del equipo de seguridad o crea un ticket JIRA para que el equipo realice un seguimiento. La aplicación Github está configurada con la URL de la API de Flask y un secreto compartido utilizado para generar la suma de comprobación SHA de la carga útil.
Una forma de configurar la URL de la API es implementar este código en un host y asignar un equilibrador de carga de aplicaciones a este host.
Nota: Al crear la aplicación, asegúrese de tener un DNS listo para el host en el que implementará contenedores Deadshot y una cadena secreta segura para el secreto del webhook.
Los administradores de Github necesitarían crear e instalar una aplicación Github en Github antes de ejecutar o implementar la aplicación Deadshot. Para saber más sobre cómo crear una aplicación Github, lea esta guía.
Nombre de la aplicación: deadshot (todo en minúsculas. Esto es importante ya que el servicio usa este nombre para recuperar comentarios anteriores que realizó sobre un PR)
URL del webhook: http(s)://your-hosted-deadshot-dns/api/v1/deadshot-webhook
Para probar esto localmente, puede crear un punto final de ngrok para alimentar la sección de webhook de su aplicación Github.
Para que esta aplicación funcione, su aplicación Github deberá habilitar los siguientes permisos y suscripciones en la página de permisos de la aplicación Github: Permisos del repositorio:
Todos los demás permisos se dejan sin cambios al valor predeterminado de Sin acceso
Suscríbete a eventos:
Finalmente haga clic en "Crear aplicación GitHub". Después de la creación exitosa de la aplicación, siga el enlace "generar una clave privada" en la sección superior de la página web de la aplicación.
Una vez generada la clave privada, guárdela en un lugar seguro. Esta clave privada generada es uno de los datos utilizados para generar un token de sesión para la interacción de la aplicación.
Después de generar la clave privada, instale la aplicación en todas las organizaciones que desee que supervise.
Esta es una aplicación de contenedores múltiples diseñada para mostrar los tres contenedores (Flask, Celery, Redis) a través de /bin/run.sh, por lo que al ejecutar la imagen de Dockerfile debería aparecer la aplicación completa.
Las tres variables siguientes son valores de cadena única proporcionados por el usuario.
Las siguientes variables de entorno cargan la ruta a los archivos con credenciales. Cargue los valores clave del archivo json en los archivos disponibles aquí antes de ejecutar la aplicación.
Nota: Si no mueve la ubicación de los archivos secretos JSON, no necesita actualizar los tres valores de variables de entorno anteriores que ya están presentes en Dockerfiles o docker-compose.yaml.
Este comando utilizará docker-compose.yaml para abrir todos los contenedores. Actualice configuración/environment/localdev.env con valores relevantes para su organización antes de ejecutar el siguiente comando
make serveUna vez que haya hecho esto y no tenga intención de utilizar Dockerfile para servir la aplicación, vaya a la sección "Verificación del estado del servidor".
Hay dos formas de compilar y ejecutar Dockerfiles. Hay cuatro Dockerfiles presentes en el repositorio, tres de los cuales se usan para generar una imagen individual para cada contenedor necesario para que este servicio funcione, y el cuarto es una configuración de Dockerfile para crear una imagen que se puede usar para abrir el archivo Dockerfile. Aplicación Flask o el trabajador de apio según el valor de la variable de entorno DEADSHOT_RUN_MODE (api o trabajador) proporcionado. Para ejecutar cualquiera de los pasos siguientes, debe estar presente en la carpeta raíz del repositorio.
Nota: Asegúrese de haber actualizado las variables de entorno en los archivos Dockerfile.api y Dockerfile.celery.
Hay tres Dockerfiles relevantes para este paso. Dockerfile.api, Dockerfile.apio y Dockerfile.redis
docker build -f Dockerfile.api -t deadshot-api:<version> .
docker build -f Dockerfile.celery -t deadshot-worker:<version> .
docker build -f Dockerfile.redis -t deadshot-redis:<version> .
Las tres imágenes creadas en los pasos anteriores se ejecutan en redes separadas, por lo que no podrán comunicarse entre sí. Para habilitar las comunicaciones entre contenedores, debemos agregarlos a una red de contenedores.
docker network create deadshot-network
Ejecute las imágenes usando la red creada en el siguiente orden: Inicie el contenedor de Redis:
docker run --net deadshot-network --name redis deadshot-redis:<version>
Inicie el contenedor de apio:
docker run --net deadshot-network deadshot-worker:<version>
Inicie el contenedor API de Flask:
docker run --net deadshot-network -p 9001:9001 deadshot-api:<version>
Para crear una única imagen de ventana acoplable para abrir la API y el trabajador de apio según la variable de entorno DEADSHOT_RUN_MODE
make buildEste comando también creará la imagen de Redis necesaria para el servicio.
Si la imagen creada se ejecuta con la variable de entorno DEADSHOT_RUN_MODE=api, aparecerá la aplicación Flask. Si la imagen se ejecuta con la variable de entorno DEADSHOT_RUN_MODE=worker, se iniciará el trabajador de apio.
Ahora que la API está lista para recibir solicitudes, navegar a http://localhost:9001/api/v1/heartbeat en un navegador debería devolver una respuesta válida o podría hacer un curl.
curl localhost:9001/api/v1/healthcheck Ambos deberían mostrar el siguiente mensaje: {"healthcheck": "ready"}
Si tiene una carga útil de webhook de la aplicación Github para su solicitud de extracción, puede ejecutar el siguiente comando curl localmente para probar su aplicación:
curl -X POST -H " content-type: application/json " -H " X-GitHub-Enterprise-Host: github.mockcompany.com " -H " X-Hub-Signature: sha1=85df4936c6396c149be94144befab41168149840 " -H " X-GitHub-Event: pull_request " -d @tests/fixtures/good_pr.json http://localhost:9001/api/v1/deadshot-webhookSi desea que la herramienta supervise otros tipos de secretos, agregue sus expresiones regulares en el archivo regex.json.
Nota: El indicador de verificación de entropía le permite buscar resultados de alta entropía además de la coincidencia de expresiones regulares.
En este momento, Deadshot solo ha probado con Github Enterprise, pero también debería funcionar con la nube de Github.
