Les passerelles API sont des composants critiques de l’infrastructure. Si un attaquant pouvait modifier la configuration des routes, il pourrait diriger le trafic vers son infrastructure. Les conséquences peuvent aller du vol de données aux pertes financières. Pire encore, le vol de données ne pouvait être remarqué qu’après une longue période en reflétant la charge. Par conséquent, la protection de votre passerelle API est de la plus haute importance.
Dans ce court article de blog, je vais énumérer quelques façons de sécuriser votre accès administrateur Apache APISIX.
Modifier les jetons d’administration
Vous pouvez gérer la configuration d’Apache APISIX via ses API HTTP. Un jeton protège chaque appel d’API. Les opérations nécessitent une X-API-KEY En-tête HTTP :
- Utilisez un jeton avec le téléspectateur rôle pour appeler les opérations de lecture
- Utilisez un jeton avec le administrateur rôle d’appeler lire et opérations d’écriture
Par exemple, pour créer une nouvelle route, je dois passer un administrateur-jeton de rôle, qui permet d’appeler des opérations d’écriture :
curl http://localhost:9180/apisix/admin/routes/1 -H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X PUT -d '
{
"methods": ["GET"],
"uri": ["/hello"],
"upstream_id": 1
}'La première et principale étape pour sécuriser votre accès consiste à modifier les valeurs de jeton par défaut :
deployment:
admin:
# Default token when use API to call for Admin API.
# *NOTE*: Highly recommended to modify this value to protect APISIX's Admin API.
# Disabling this configuration item means that the Admin API does not
# require any authentication.
admin_key:
- name: admin
key: edd1c9f034335f136f87ad84b625c8f1 #1
role: admin # admin: manage all configuration data
# viewer: only can view configuration data
- name: viewer
key: 4054f7cf07e344346cd3f287985e76a2 #1
role: viewer- Changes le!
Vous voudrez peut-être sécuriser encore plus les jetons – cela dépend de votre plate-forme. Par exemple, vous souhaiterez peut-être stocker des jetons en tant que Secret et injectez-les au démarrage du conteneur.
Restreindre les IP de liaison
Un serveur peut avoir plusieurs adresses IP provenant de différentes cartes réseau. Par exemple, une passerelle API aurait au moins deux adaptateurs réseau :
- Un adaptateur public pour être accessible depuis Internet
- Un interne pour l’accès à l’intérieur
Par défaut, Apache APISIX se lie à tous les adaptateurs réseau trouvés sur le serveur au démarrage. Le scénario ci-dessus signifie qu’il sera accessible d’Internet. Nous devrions limiter l’accès de l’intérieur uniquement.
Nous pouvons définir à quelle interface réseau Apache APISIX peut se lier dans la configuration :
deployment:
admin:
admin_listen:
ip: 0.0.0.0 # Specific IP, if not set, the default value is `0.0.0.0` #1- Changes le!
Restreindre les IP autorisées
Même si vous limitez l’accès aux seules adresses IP à l’intérieur de votre réseau d’entreprise, vous souhaitez que seules certaines machines accèdent à la configuration de la passerelle API. Si tel était le cas, un attaquant accédant à la machine d’un comptable pourrait s’en servir pour tenter d’attaquer l’API Gateway.
Vous pouvez restreindre l’accès IP avec des politiques de réseau – et vous devriez. Cependant, vous pouvez également implémenter cette restriction sur la passerelle API : elle peut permettre un contrôle plus précis et des modifications plus agiles ; les politiques de réseau sont généralement difficiles à modifier.
Voici l’extrait pertinent pour Apache APISIX :
deployment:
admin:
allow_admin:
- 127.0.0.0/24 # If we don't set any IP list, then any IP access is allowed by default
#- "::/64" #1- Modifiez-le en fonction de la topologie de votre réseau.
TLS mutuel
Si l’on parle d’authentification, une solution consiste à utiliser un certificat numérique. Le mécanisme d’authentification de bas niveau le plus répandu aujourd’hui est TLS. TLS permet aux serveurs de prouver leur identité. De plus, il garde les données échangées privées et les empêche d’être falsifiées.
Mutual TLS fonctionne des deux côtés afin que le serveur prouve son identité au client et le client prouve son identité au serveur.
Voici l’extrait de configuration pertinent pour définir l’administrateur mTLS dans Apache APISIX :
deployment:
admin:
https_admin: true # enable HTTPS when use a separate port for Admin API
# Admin API will use conf/apisix_admin_api.crt and conf/apisix_admin_api.key as certificate
admin_api_mtls:
admin_ssl_ca_cert: "/data/certs/mtls_ca.crt" # Path of your self-signed ca cert
admin_ssl_cert: "/data/certs/mtls_server.crt" # Path of your self-signed server side cert
admin_ssl_cert_key: "/data/certs/mtls_server.key" # Path of your self-signed server side keyMode autonome
Enfin et surtout, on peut complètement déplacer la configuration de etcd dans un fichier statique (YAML). Dans ce cas, aucune API d’administration n’est disponible pour mettre à jour la configuration. Ce modèle de déploiement est appelé mode autonome.
En mode autonome, la seule façon de modifier la configuration est de mettre à jour le fichier statique : Apache APISIX vérifiera les modifications à intervalles réguliers et se mettra à jour en conséquence. C’est un excellent moyen d’appliquer les principes GitOps avec Apache APISIX.
En attendant, vous pouvez configurer le mode autonome comme suit :
deployment:
role: data_plane
role_data_plane:
config_provider: yamlNotez que le mode autonome rend toutes les autres options de sécurisation inutiles, car il n’y a plus d’API Admin à sécuriser.
Conclusion
Vous devez sécuriser les API Gateways contre les accès indésirables car ce sont des cibles précieuses pour les mauvais acteurs. Dans cet article, j’ai montré plusieurs options non exclusives que vous devriez envisager pour sécuriser Apache APISIX.
Enfin, j’ai décrit comment vous pouvez le faire sans l’API Admin via le mode de déploiement autonome dédié. Attendez-vous à un futur article de blog sur la façon de l’utiliser avec GitOps.