Déployer le relais
Passer d'un abonnement Azure vide à un relais qui répond. Tout se fait dans le navigateur : rien à installer sur votre poste.
Ce dont vous avez besoin
- Vos trois identifiants de licence Secure Exchanges : numéro de série, utilisateur d'API et mot de passe d'API, trois GUID. Voir Identifiants et environnements.
- L'environnement de votre licence : production ou préproduction.
- Un abonnement Azure, avec le rôle Contributor pour créer des ressources.
Étape 1 : ouvrir le gabarit
Le portail Azure s'ouvre sur un formulaire de déploiement.
Étape 2 : choisir où installer
| Champ | Ce que vous mettez |
|---|---|
| Abonnement | Celui qui portera les coûts. |
| Groupe de ressources | Un groupe dédié, par exemple rg-secure-exchanges : le supprimer retire tout d'un coup. Les ressources sont créées dans sa région. |
| Région | La plus proche de vous, par exemple une région canadienne. |
| Nom de la Function App | Laissez vide : le nom se-relay- suivi d'un suffixe propre au groupe de ressources est généré. Sinon, de 3 à 40 caractères, lettres, chiffres et traits d'union, commençant et finissant par une lettre ou un chiffre. |
Étape 3 : fournir vos identifiants
Option A : les saisir
Trois champs masqués, un GUID chacun. Ce sont des paramètres sécurisés : Azure ne les inscrit pas dans l'historique de déploiement. Ils sont écrits dans les paramètres d'application de la Function App, lisibles par les personnes qui peuvent consulter cette configuration. Si votre politique l'exclut, prenez l'option B.
Option B : les lire dans Azure Key Vault
Choisissez Read them from Azure Key Vault, sélectionnez votre coffre (la liste montre les coffres de l'abonnement choisi), puis saisissez le nom exact des trois secrets. Les noms proposés, se-serial, se-api-user et se-api-password, ne sont que des suggestions.
Les valeurs ne sont alors stockées ni dans la configuration de l'application ni dans l'historique de déploiement : seule une référence y figure. Azure lit la dernière version de chaque secret avec l'identité managée de l'application et la lui fournit à l'exécution.
Après le déploiement, autorisez l'application à lire le coffre. Dans Cloud Shell, en remplaçant les trois noms :
az role assignment create --role "Key Vault Secrets User" --assignee-object-id $(az functionapp identity show --resource-group <votre-groupe> --name <votre-application> --query principalId -o tsv) --assignee-principal-type ServicePrincipal --scope $(az keyvault show --name <votre-coffre> --query id -o tsv)
Puis redémarrez l'application.
- Cette commande vaut pour un coffre en mode d'autorisation Azure RBAC. Si votre coffre utilise des stratégies d'accès, accordez plutôt à l'identité de l'application la permission Get sur les secrets.
- Il faut être Owner, User Access Administrator ou Role Based Access Control Administrator sur le coffre : le rôle Contributor ne permet pas d'attribuer un rôle.
- Si le coffre est derrière un pare-feu ou un point de terminaison privé, l'application doit pouvoir le joindre.
Les autres champs
| Champ | Ce que vous mettez |
|---|---|
| Secure Exchanges environment | Production, ou Preview si votre licence est sur l'environnement de préproduction |
| Default language | fr-CA ou en-CA : la langue des pages vues par vos destinataires quand un appel n'en précise pas |
L'onglet Sizing règle la mémoire par instance (512, 2 048 ou 4 096 Mo, 512 par défaut) et le plafond d'instances (de 40 à 1 000, 40 par défaut). Ne les modifiez que si le soutien de Secure Exchanges vous le demande.
Étape 4 : créer
Cliquez sur Vérifier + créer, puis sur Créer, et attendez la fin du déploiement.
Étape 5 : installer le code
L'infrastructure est prête, mais l'application est vide.
- Sur la page du déploiement, ouvrez Sorties. Si vous l'avez fermée : groupe de ressources, Paramètres, Déploiements, le déploiement, Sorties.
- Copiez la valeur de
step1_installationCommand. Elle sélectionne déjà le bon abonnement. - Ouvrez Cloud Shell (
>_, en haut du portail), en Bash. - Collez la commande et appuyez sur Entrée. Attendez qu'elle se termine sans erreur.
Étape 6 : récupérer l'adresse et la clé
| Sortie | Contenu |
|---|---|
step2_relayUrlWithKey |
L'adresse de /api/enveloppe, clé comprise : https://<hôte>/api/enveloppe?code=<clé> |
step4_accessKey |
La clé seule |
step3_testCommand |
Une commande curl prête sur /api/version |
La clé est la clé d'hôte default de la Function App : elle vaut pour les trois routes. Traitez-la comme un mot de passe : qui la possède peut créer des enveloppes et envoyer des messages sur votre licence.
Attention
Ces sorties affichent la clé en clair. Toute personne qui peut consulter les déploiements du groupe de ressources, même avec le seul rôle Reader, peut la lire. Limitez l'accès au groupe, et renouvelez la clé si vous en doutez : voir Configurer et sécuriser.
Étape 7 : vérifier
Lancez
step3_testCommand. Une réponse 200 prouve que le code est installé et que la clé est valide, mais pas que vos identifiants sont corrects : cette route n'appelle pas Secure Exchanges.Créez une enveloppe de test, en remplaçant l'hôte, la clé et l'adresse de destination :
curl -s -X POST "https://<hôte>/api/enveloppe" -H "x-functions-key: <clé>" -H "Content-Type: application/json" -d '{"subject":"Test","destination":"vous@example.com"}'Réponse attendue :
{"status":200,"url":"https://www.secure-exchanges.com/...","repId":"...","error":null}
Le champ url est le lien d'enveloppe : ouvrez-le pour voir ce que verra votre destinataire. Pour toute autre réponse, voir Dépannage.