Politiques de déploiement de modèles

Avant de déployer un modèle à l'aide de la ressource correspondante, vous devez créer un groupe d'utilisateurs autorisés à effectuer cette opération.

Vous pouvez également créer un groupe dynamique de ressources (telles que des sessions de carnet) autorisé à créer un déploiement. Dans ce cas, toute personne pouvant accéder à la session de carnet peut prendre l'identité de cette dernière et créer un déploiement de modèle. La méthode d'authentification de la session de carnet utilise des principaux de ressources.

La même formule s'applique lors de l'appel du point d'extrémité du modèle après le déploiement. Un groupe d'utilisateurs ou de ressources doit être autorisé à appeler le modèle.

Nous pensons que les exemples suivants sont les énoncés de politique courants à utiliser avec un déploiement de modèle. Suivez ce lien pour voir d'autres exemples de politiques de déploiement de modèle.

Politiques de gestion du déploiement de modèles

Permet à un groupe d'utilisateurs, <group-name>, d'effectuer toutes les opérations CRUD sur les modèles stockés dans le catalogue de modèles. Tout utilisateur qui souhaite déployer un modèle au moyen d'un déploiement doit également pouvoir accéder au modèle en question.

allow group <group-name> to manage data-science-models 
in compartment <compartment-name>

Permet à un groupe d'utilisateurs, <group-name>, d'effectuer toutes les opérations CRUD, y compris l'appel du point d'extrémité d'inférence, sur les ressources de déploiement de modèle d'un compartiment particulier. Vous pouvez modifier le verbe manage pour limiter ce que les utilisateurs peuvent faire.

allow group <group-name> to manage data-science-model-deployments 
in compartment <compartment-name>

Permet à un groupe dynamique de ressources (comme les sessions de carnet) d'effectuer toutes les opérations CRUD, y compris l'appel du point d'extrémité d'inférence, sur les ressources de déploiement de modèle d'un compartiment particulier. Le verbe manage peut être modifié pour limiter ce que les ressources peuvent faire.

allow dynamic-group <dynamic-group-name> to manage  data-science-model-deployments 
in compartment <compartment-name>

Les exemples de politique précédents sont permissifs. Vous pouvez créer des politiques plus restrictives. Un exemple courant consiste à restreindre les utilisateurs ou les ressources qui peuvent appeler le point d'extrémité d'inférence du déploiement de modèle.

Autoriser l'accès à la politique de point d'extrémité de prédiction ou de diffusion en continu

allow group <group-name> to manage data-science-model-deployments 
in compartment <compartment-name>

Vous pouvez également autoriser les ressources à faire la même chose. Seul le groupe dynamique de ressources du groupe dynamique spécifié peut appeler le point d'extrémité du modèle pour les ressources de déploiement de modèle créées dans un compartiment particulier.

allow dynamic-group <dynamic-group-name-2> to {DATA_SCIENCE_MODEL_DEPLOYMENT_PREDICT} 
in compartment <compartment-name>

Autoriser le déploiement de modèle à accéder à un seau Conda publié

(Facultatif) Permet à un déploiement de modèle d'accéder aux environnements Conda publiés stockés dans un seau de stockage d'objets. Cela est nécessaire si vous voulez utiliser les environnements Conda publiés pour saisir les dépendances tierces d'un modèle.

allow any-user to read objects in compartment <compartment-name>
where ALL { request.principal.type='datasciencemodeldeployment', 
target.bucket.name=<published-conda-envs-bucket-name> }

Accorder au déploiement de modèle l'accès au service de journalisation

(Facultatif) Permet à un déploiement de modèle d'émettre des journaux vers le service de journalisation. Vous avez besoin de cette politique si vous utilisez la journalisation dans un déploiement de modèle. Cette déclaration est permissive. Par exemple, vous pouvez restreindre l'autorisation d'utiliser le contenu du journal dans un compartiment spécifique.

allow any-user to use log-content in tenancy 
where ALL {request.principal.type = 'datasciencemodeldeployment'}

Accorder au déploiement de modèle l'accès à un seau de stockage d'objets

(Facultatif) Permet à un déploiement de modèle d'accéder à un seau de stockage d'objets qui réside dans une location. Par exemple, un modèle déployé lit des fichiers (fichier CSV de consultation) à partir d'un seau de stockage d'objets que vous gérez.

allow any-user to read objects in compartment <compartment-name> 
where ALL { request.principal.type='datasciencemodeldeployment', target.bucket.name=<bucket-name> }

Accorder au déploiement de modèle l'accès à un conteneur personnalisé à l'aide d'un principal de ressource

Les politiques peuvent être configurées comme suit :

Configurer des groupes dynamiques et créer des stratégies dans le groupe dynamique

Créer un groupe dynamique :

ALL { resource.type = 'datasciencemodeldeployment' }

Permet à un groupe dynamique de lire un conteneur personnalisé.

allow dynamic-group <dynamic-group-name> to read repos in compartment <compartment-name> where ANY {
    request.operation='ReadDockerRepositoryMetadata',
    request.operation='ReadDockerRepositoryManifest',
    request.operation='PullDockerLayer'

Si le référentiel se trouve dans le compartiment racine, autorisez la lecture pour la location :

allow dynamic-group <dynamic-group-name> to read repos in tenancy where ANY {
    request.operation='ReadDockerRepositoryMetadata',
    request.operation='ReadDockerRepositoryManifest',
    request.operation='PullDockerLayer'
}

Autres méthodes d'authentification et d'autorisation

Le déploiement de modèle prend uniquement en charge l'autorisation et l'authentification définies par le service de gestion des identités et des accès (GIA) pour OCI. Le déploiement de modèle ne prend pas en charge d'autres méthodes d'autorisation et d'authentification, telles que OAuth ou l'authentification d'accès de base.

Documentation sur Oracle Cloud Infrastructure