Protege tu API_KEY con Github Secrets y Github Actions en Flutter

Una de las acciones de seguridad más simples que puedes hacer en tu aplicación sin duda es esconder las claves de cualquier API que estés consumiendo, especialmente si es una key privada.

Primer paso: evitar hacer commits de tus claves

Lo primero que nos viene a la cabeza es simplemente añadir a .gitignore aquellos archivos que contengan nuestras claves.

En mi caso tengo una estructura de la aplicación hecha por packages, y ahí guardo los repositories, apis, etc.

Si no tienes ningún tipo dei integración continua probablemente esto sea suficiente para ti. En caso contrario el problema viene cuando necesitas utilizar esas claves en tu CI

Te recomiendo estas dos charlas que tuvimos en el canal de Flutter España en las que hablamos un poco más sobre CI y diversas opciones que tienes.

Segundo paso: crear una nueva Secret

Si has seguido el primer paso, el problema que tienes ahora es que tu repositorio no tiene conocimiento alguno de las claves de tu aplicación y probablemente tu flutter analyze o flutter test estén fallando porque no encuentran el archivo con tus claves.

Para resolver esto utilizaremos los secretos, o Github Secrets.

Para ello nos iremos en nuestro repositorio a Settings/Secrets y crearemos una nueva clave.

En la mayoría de los casos, con poner la clave tal cual sería suficiente, pero en nuestro caso vamos a almacenar en base64 nuestro archivo entero, para ello previamente por consola ejecutamos el siguiente comando y pegamos su resultado en el campo “Value” de nuestra nueva secret.

base64 packages/time_zone_api/lib/src/consts/secrets.dart

Tercer paso: utilizar nuestra nueva secret en nuestro workflow

Este paso es muy sencillo, pero variará en función de cómo tengas configurado el workflow de las github actions. Como decía previamente, yo tengo organizado mi proyecto por packages, y cada uno de ellos lleva asociado un workflow distinto.

Si no has hecho commit previamente de tu archivo secrets, tu repositorio no tendrá referencia a ese archivo , por lo que si intentas añadirle información te dará un error que no es capaz de encontrarlo, para ello simplemente usamos el comando mkdir que generará el directorio.

En mi caso es “lib/src…” porque estoy trabajando en el directorio del propio package.

Si por ejemplo estuviéramos en otro directorio y necesitamos crear el archivo en uno distinto, simplemente ejecutamos el mismo proceso pero con el directorio adecuado.

Por último, para crear el archivo tienes varias opciones, yo he utilizado la más simple que es usar una Github Action que ya había creada.

Pequeña aclaración: esta action se ve que no tiene en cuenta el path donde estás ejecutando la acción, por lo que tendrás que poner el path completo.

Si todo ha ido correctamente el workflow debería pasar ahora sin problemas.

Y eso es todo, cualquier duda me puedes encontrar en mi Twitter. Espero que os sea útil y hasta la próxima!