Udostępnij za pośrednictwem


Uruchamianie zadań w ramach kont użytkowników w usłudze Batch

Uwaga

Konta użytkowników omówione w tym artykule różnią się od kont użytkowników używanych w przypadku protokołu RDP (Remote Desktop Protocol) lub Secure Shell (SSH) ze względów bezpieczeństwa.

Aby nawiązać połączenie z węzłem z uruchomioną konfiguracją maszyny wirtualnej z systemem Linux za pośrednictwem protokołu SSH, zobacz Instalowanie i konfigurowanie środowiska xrdp do używania pulpitu zdalnego z systemem Ubuntu. Aby nawiązać połączenie z węzłami z systemem Windows za pośrednictwem protokołu RDP, zobacz Jak nawiązać połączenie i zalogować się do maszyny wirtualnej platformy Azure z systemem Windows.

Aby nawiązać połączenie z węzłem działającym za pośrednictwem protokołu RDP, zobacz Włączanie połączenia pulpitu zdalnego dla roli w usłudze Azure Cloud Services.

Zadanie w Azure Batch zawsze jest uruchamiane w ramach konta użytkownika. Domyślnie zadania są uruchamiane na kontach użytkowników standardowych bez uprawnień administratora. W przypadku niektórych scenariuszy możesz skonfigurować konto użytkownika, w ramach którego ma zostać uruchomione zadanie. W tym artykule omówiono typy kont użytkowników i sposób ich konfigurowania na potrzeby danego scenariusza.

Typy kont użytkowników

Azure Batch udostępnia dwa typy kont użytkowników do uruchamiania zadań:

  • Konta użytkowników automatycznych. Konta użytkowników automatycznie są wbudowanymi kontami użytkowników, które są tworzone automatycznie przez usługę Batch. Domyślnie zadania są uruchamiane na koncie użytkownika automatycznego. Możesz skonfigurować specyfikację automatycznego użytkownika dla zadania, aby wskazać, w ramach którego konta użytkownika automatycznego ma zostać uruchomione zadanie. Specyfikacja automatycznego użytkownika umożliwia określenie poziomu podniesienia uprawnień i zakresu konta użytkownika automatycznego, które uruchomi zadanie.

  • Nazwane konto użytkownika. Podczas tworzenia puli można określić co najmniej jedno nazwane konto użytkownika dla puli. Każde konto użytkownika jest tworzone w każdym węźle puli. Oprócz nazwy konta należy określić hasło konta użytkownika, poziom podniesienia uprawnień i, w przypadku pul systemu Linux, klucz prywatny SSH. Po dodaniu zadania można określić nazwane konto użytkownika, w ramach którego ma zostać uruchomione to zadanie.

Ważne

Usługa Batch w wersji 2017-01-01.4.0 wprowadziła zmianę powodującą niezgodność, która wymaga zaktualizowania kodu w celu wywołania tej wersji lub nowszej. Zobacz Aktualizowanie kodu do najnowszej biblioteki klienta usługi Batch , aby uzyskać szybkie wskazówki dotyczące aktualizowania kodu usługi Batch ze starszej wersji.

Dostęp konta użytkownika do plików i katalogów

Zarówno konto użytkownika automatycznego, jak i nazwane konto użytkownika mają dostęp do odczytu/zapisu do katalogu roboczego zadania zadania, katalogu udostępnionego i katalogu zadań z wieloma wystąpieniami. Oba typy kont mają dostęp do odczytu do katalogów uruchamiania i przygotowywania zadań.

Jeśli zadanie jest uruchamiane na tym samym koncie, które zostało użyte do uruchamiania zadania podrzędnego uruchamiania, zadanie ma dostęp do odczytu i zapisu do katalogu zadań uruchamiania. Podobnie, jeśli zadanie jest uruchamiane na tym samym koncie, które zostało użyte do uruchamiania zadania podrzędnego przygotowania zadania, zadanie ma dostęp do odczytu i zapisu do katalogu zadań przygotowania zadania. Jeśli zadanie jest uruchamiane na innym koncie niż zadanie podrzędne uruchamiania lub zadanie podrzędne, ma tylko dostęp do odczytu do odpowiedniego katalogu.

Aby uzyskać więcej informacji na temat uzyskiwania dostępu do plików i katalogów z zadania, zobacz Pliki i katalogi.

Podwyższony poziom dostępu dla zadań

Poziom podniesienia uprawnień konta użytkownika wskazuje, czy zadanie jest uruchamiane z podwyższonym poziomem dostępu. Zarówno konto użytkownika automatycznego, jak i nazwane konto użytkownika mogą być uruchamiane z podwyższonym poziomem uprawnień dostępu. Dostępne są dwie opcje poziomu podniesienia uprawnień:

  • Nieadmin: Zadanie jest uruchamiane jako użytkownik standardowy bez podwyższonego poziomu dostępu. Domyślny poziom podniesienia uprawnień dla konta użytkownika usługi Batch to zawsze NonAdmin.
  • Administracja: zadanie jest uruchamiane jako użytkownik z podwyższonym poziomem dostępu i działa z pełnymi uprawnieniami administratora.

Konta użytkowników automatycznych

Domyślnie zadania są uruchamiane w usłudze Batch w ramach konta użytkownika automatycznego, jako użytkownik standardowy bez podwyższonego poziomu dostępu i z zakresem puli. Zakres puli oznacza, że zadanie jest uruchamiane na koncie użytkownika automatycznego, które jest dostępne dla dowolnego zadania w puli. Aby uzyskać więcej informacji na temat zakresu puli, zobacz Uruchamianie zadania jako użytkownik automatyczny z zakresem puli.

Alternatywą dla zakresu puli jest zakres zadań. Gdy specyfikacja automatycznego użytkownika jest skonfigurowana dla zakresu zadań, usługa Batch tworzy tylko konto użytkownika automatycznego dla tego zadania.

Istnieją cztery możliwe konfiguracje dla specyfikacji automatycznego użytkownika, z których każda odpowiada unikatowej kontu użytkownika automatycznego:

  • Dostęp bez uprawnień administratora z zakresem zadań
  • Administracja (podwyższony poziom) dostępu z zakresem zadań
  • Dostęp bez uprawnień administratora z zakresem puli
  • Administracja dostęp z zakresem puli

Ważne

Zadania uruchomione w zakresie zadań nie mają de facto dostępu do innych zadań w węźle. Jednak złośliwy użytkownik z dostępem do konta może obejść to ograniczenie, przesyłając zadanie uruchamiane z uprawnieniami administratora i uzyskuje dostęp do innych katalogów zadań. Złośliwy użytkownik może również nawiązać połączenie z węzłem za pomocą protokołu RDP lub SSH. Ważne jest, aby chronić dostęp do kluczy konta usługi Batch, aby zapobiec takiemu scenariuszowi. Jeśli podejrzewasz, że Twoje konto mogło zostać naruszone, pamiętaj o ponownej wygenerowaniu kluczy.

Uruchamianie zadania jako użytkownik automatyczny z podwyższonym poziomem dostępu

Możesz skonfigurować specyfikację automatycznego użytkownika dla uprawnień administratora, gdy musisz uruchomić zadanie z podwyższonym poziomem dostępu. Na przykład zadanie uruchamiania może wymagać podwyższonego poziomu dostępu do instalowania oprogramowania w węźle.

Uwaga

Używaj dostępu z podwyższonym poziomem uprawnień tylko wtedy, gdy jest to konieczne. Najlepsze rozwiązania zalecają przyznanie minimalnych uprawnień niezbędnych do osiągnięcia żądanego wyniku. Jeśli na przykład zadanie uruchamiania instaluje oprogramowanie dla bieżącego użytkownika, a nie dla wszystkich użytkowników, może być możliwe unikanie udzielania podwyższonego poziomu dostępu do zadań. Możesz skonfigurować specyfikację automatycznego użytkownika dla zakresu puli i dostępu bez uprawnień administratora dla wszystkich zadań, które muszą być uruchamiane na tym samym koncie, w tym podzadania uruchamiania.

Poniższe fragmenty kodu pokazują, jak skonfigurować specyfikację autoużytkownika. W przykładach ustawiono poziom podniesienia uprawnień na Admin i zakres na Taskwartość .

Batch .NET

task.UserIdentity = new UserIdentity(new AutoUserSpecification(elevationLevel: ElevationLevel.Admin, scope: AutoUserScope.Task));

Batch Java

taskToAdd.withId(taskId)
        .withUserIdentity(new UserIdentity()
            .withAutoUser(new AutoUserSpecification()
                .withElevationLevel(ElevationLevel.ADMIN))
                .withScope(AutoUserScope.TASK));
        .withCommandLine("cmd /c echo hello");

Batch Python

user = batchmodels.UserIdentity(
    auto_user=batchmodels.AutoUserSpecification(
        elevation_level=batchmodels.ElevationLevel.admin,
        scope=batchmodels.AutoUserScope.task))
task = batchmodels.TaskAddParameter(
    id='task_1',
    command_line='cmd /c "echo hello world"',
    user_identity=user)
batch_client.task.add(job_id=jobid, task=task)

Uruchamianie zadania jako użytkownik automatyczny z zakresem puli

Po aprowizacji węzła na każdym węźle w puli są tworzone dwa konta użytkowników automatycznych dla całej puli, jedno z podwyższonym poziomem dostępu i jedno bez podwyższonego poziomu dostępu. Ustawienie zakresu automatycznego użytkownika na zakres puli dla danego zadania powoduje uruchomienie zadania w ramach jednego z tych dwóch kont użytkowników automatycznych dla całej puli.

Po określeniu zakresu puli dla użytkownika automatycznego wszystkie zadania uruchamiane z dostępem administratora są uruchamiane w ramach tego samego konta użytkownika automatycznego w całej puli. Podobnie zadania uruchamiane bez uprawnień administratora są również uruchamiane w ramach pojedynczego konta użytkownika automatycznego w całej puli.

Uwaga

Dwa konta automatycznego użytkownika w całej puli są oddzielnymi kontami. Zadania uruchomione na koncie administracyjnym obejmującym całą pulę nie mogą udostępniać danych za pomocą zadań uruchomionych na koncie standardowym i na odwrót.

Zaletą uruchamiania na tym samym koncie użytkownika automatycznego jest to, że zadania podrzędne mogą udostępniać dane innym podzadaniam uruchomionym w tym samym węźle.

Udostępnianie wpisów tajnych między zadaniami jest jednym ze scenariuszy, w którym przydatne jest uruchamianie zadań w ramach jednego z dwóch kont użytkowników automatycznych w całej puli. Załóżmy na przykład, że zadanie uruchamiania musi aprowizować wpis tajny w węźle, którego mogą używać inne zadania. Możesz użyć interfejsu API ochrony danych systemu Windows (DPAPI), ale wymaga uprawnień administratora. Zamiast tego można chronić wpis tajny na poziomie użytkownika. Zadania uruchomione na tym samym koncie użytkownika mogą uzyskiwać dostęp do wpisu tajnego bez podwyższonego poziomu dostępu.

Innym scenariuszem, w którym można uruchamiać zadania w ramach konta użytkownika automatycznego z zakresem puli, jest udział plików interfejsu MPI (Message Passing Interface). Udział plików MPI jest przydatny, gdy węzły w zadaniu MPI muszą pracować nad tymi samymi danymi plików. Węzeł główny tworzy udział plików, do którego węzły podrzędne mogą uzyskiwać dostęp, jeśli są uruchomione na tym samym koncie użytkownika automatycznego.

Poniższy fragment kodu ustawia zakres automatycznego użytkownika na zakres puli dla zadania w usłudze Batch .NET. Poziom podniesienia uprawnień zostanie pominięty, więc zadanie jest uruchamiane w ramach standardowego konta automatycznego użytkownika w całej puli.

task.UserIdentity = new UserIdentity(new AutoUserSpecification(scope: AutoUserScope.Pool));

Nazwane konta użytkowników

Podczas tworzenia puli można zdefiniować nazwane konta użytkowników. Nazwane konto użytkownika ma podaną nazwę i hasło. Możesz określić poziom podniesienia uprawnień dla nazwanego konta użytkownika. W przypadku węzłów systemu Linux można również podać klucz prywatny SSH.

Konto użytkownika o nazwie istnieje we wszystkich węzłach w puli i jest dostępne dla wszystkich zadań uruchomionych w tych węzłach. Możesz zdefiniować dowolną liczbę nazwanych użytkowników dla puli. Po dodaniu zadania lub kolekcji zadań można określić, że zadanie jest uruchamiane w ramach jednego z nazwanych kont użytkowników zdefiniowanych w puli.

Nazwane konto użytkownika jest przydatne, gdy chcesz uruchamiać wszystkie zadania w zadaniu w ramach tego samego konta użytkownika, ale odizolować je od zadań uruchomionych w innych zadaniach jednocześnie. Można na przykład utworzyć nazwanego użytkownika dla każdego zadania i uruchomić podzadania każdego zadania w ramach tego nazwanego konta użytkownika. Każde zadanie może następnie udostępnić wpis tajny swoim własnym zadaniu, ale nie z zadaniami uruchomionymi w innych zadaniach.

Możesz również użyć nazwanego konta użytkownika, aby uruchomić zadanie, które ustawia uprawnienia do zasobów zewnętrznych, takich jak udziały plików. Za pomocą nazwanego konta użytkownika możesz kontrolować tożsamość użytkownika i używać tej tożsamości użytkownika do ustawiania uprawnień.

Nazwane konta użytkowników umożliwiają bez hasła protokół SSH między węzłami systemu Linux. Możesz użyć nazwanego konta użytkownika z węzłami systemu Linux, które muszą uruchamiać zadania obejmujące wiele wystąpień. Każdy węzeł w puli może uruchamiać zadania podrzędne na koncie użytkownika zdefiniowanym w całej puli. Aby uzyskać więcej informacji na temat zadań obejmujących wiele wystąpień, zobacz Używanie zadań z wieloma wystąpieniami do uruchamiania aplikacji MPI.

Tworzenie nazwanych kont użytkowników

Aby utworzyć nazwane konta użytkowników w usłudze Batch, dodaj kolekcję kont użytkowników do puli. Poniższe fragmenty kodu pokazują, jak utworzyć nazwane konta użytkowników na platformie .NET, Java i w języku Python. Te fragmenty kodu pokazują, jak utworzyć konta administratora i nienależące do administratora w puli.

Przykład dla usługi Batch dla platformy .NET (Windows)

CloudPool pool = null;
Console.WriteLine("Creating pool [{0}]...", poolId);

// Create a pool using Virtual Machine Configuration.
pool = batchClient.PoolOperations.CreatePool(
    poolId: poolId,
    targetDedicatedComputeNodes: 3,
    virtualMachineSize: "standard_d1_v2",
    VirtualMachineConfiguration: new VirtualMachineConfiguration(
    imageReference: new ImageReference(
                        publisher: "MicrosoftWindowsServer",
                        offer: "WindowsServer",
                        sku: "2019-datacenter-core",
                        version: "latest"),
    nodeAgentSkuId: "batch.node.windows amd64");

// Add named user accounts.
pool.UserAccounts = new List<UserAccount>
{
    new UserAccount("adminUser", "xyz123", ElevationLevel.Admin),
    new UserAccount("nonAdminUser", "123xyz", ElevationLevel.NonAdmin),
};

// Commit the pool.
await pool.CommitAsync();

Przykład dla platformy .NET usługi Batch (Linux)

CloudPool pool = null;

// Obtain a collection of all available node agent SKUs.
List<NodeAgentSku> nodeAgentSkus =
    batchClient.PoolOperations.ListNodeAgentSkus().ToList();

// Define a delegate specifying properties of the VM image to use.
Func<ImageReference, bool> isUbuntu1804 = imageRef =>
    imageRef.Publisher == "Canonical" &&
    imageRef.Offer == "UbuntuServer" &&
    imageRef.Sku.Contains("20.04-LTS");

// Obtain the first node agent SKU in the collection that matches
// Ubuntu Server 20.04.
NodeAgentSku ubuntuAgentSku = nodeAgentSkus.First(sku =>
    sku.VerifiedImageReferences.Any(isUbuntu2004));

// Select an ImageReference from those available for node agent.
ImageReference imageReference =
    ubuntuAgentSku.VerifiedImageReferences.First(isUbuntu2004);

// Create the virtual machine configuration to use to create the pool.
VirtualMachineConfiguration virtualMachineConfiguration =
    new VirtualMachineConfiguration(imageReference, ubuntuAgentSku.Id);

Console.WriteLine("Creating pool [{0}]...", poolId);

// Create the unbound pool.
pool = batchClient.PoolOperations.CreatePool(
    poolId: poolId,
    targetDedicatedComputeNodes: 3,
    virtualMachineSize: "Standard_A1",
    virtualMachineConfiguration: virtualMachineConfiguration);
// Add named user accounts.
pool.UserAccounts = new List<UserAccount>
{
    new UserAccount(
        name: "adminUser",
        password: "xyz123",
        elevationLevel: ElevationLevel.Admin,
        linuxUserConfiguration: new LinuxUserConfiguration(
            uid: 12345,
            gid: 98765,
            sshPrivateKey: new Guid().ToString()
            )),
    new UserAccount(
        name: "nonAdminUser",
        password: "123xyz",
        elevationLevel: ElevationLevel.NonAdmin,
        linuxUserConfiguration: new LinuxUserConfiguration(
            uid: 45678,
            gid: 98765,
            sshPrivateKey: new Guid().ToString()
            )),
};

// Commit the pool.
await pool.CommitAsync();

Przykład dla języka Java wsadowego

List<UserAccount> userList = new ArrayList<>();
userList.add(new UserAccount().withName(adminUserAccountName).withPassword(adminPassword).withElevationLevel(ElevationLevel.ADMIN));
userList.add(new UserAccount().withName(nonAdminUserAccountName).withPassword(nonAdminPassword).withElevationLevel(ElevationLevel.NONADMIN));
PoolAddParameter addParameter = new PoolAddParameter()
        .withId(poolId)
        .withTargetDedicatedNodes(POOL_VM_COUNT)
        .withVmSize(POOL_VM_SIZE)
        .withVirtualMachineConfiguration(configuration)
        .withUserAccounts(userList);
batchClient.poolOperations().createPool(addParameter);

Przykład dla języka Python w usłudze Batch

users = [
    batchmodels.UserAccount(
        name='pool-admin',
        password='******',
        elevation_level=batchmodels.ElevationLevel.admin)
    batchmodels.UserAccount(
        name='pool-nonadmin',
        password='******',
        elevation_level=batchmodels.ElevationLevel.non_admin)
]
pool = batchmodels.PoolAddParameter(
    id=pool_id,
    user_accounts=users,
    virtual_machine_configuration=batchmodels.VirtualMachineConfiguration(
        image_reference=image_ref_to_use,
        node_agent_sku_id=sku_to_use),
    vm_size=vm_size,
    target_dedicated=vm_count)
batch_client.pool.add(pool)

Uruchamianie zadania w ramach nazwanego konta użytkownika z podwyższonym poziomem dostępu

Aby uruchomić zadanie jako użytkownik z podwyższonym poziomem uprawnień, ustaw właściwość UserIdentity zadania na nazwane konto użytkownika, które zostało utworzone z właściwością ElevationLevel ustawioną na Adminwartość .

Ten fragment kodu określa, że zadanie powinno być uruchamiane w ramach nazwanego konta użytkownika. To nazwane konto użytkownika zostało zdefiniowane w puli podczas tworzenia puli. W tym przypadku nazwane konto użytkownika zostało utworzone z uprawnieniami administratora:

CloudTask task = new CloudTask("1", "cmd.exe /c echo 1");
task.UserIdentity = new UserIdentity(AdminUserAccountName);

Aktualizowanie kodu do najnowszej biblioteki klienta usługi Batch

Usługa Batch w wersji 2017-01-01.4.0 wprowadziła zmianę powodującą niezgodność, zastępując właściwość runElevated dostępną we wcześniejszych wersjach właściwością userIdentity . W poniższych tabelach przedstawiono proste mapowanie, którego można użyć do zaktualizowania kodu z wcześniejszych wersji bibliotek klienckich.

Batch .NET

Jeśli kod używa... Zaktualizuj go do....
CloudTask.RunElevated = true; CloudTask.UserIdentity = new UserIdentity(new AutoUserSpecification(elevationLevel: ElevationLevel.Admin));
CloudTask.RunElevated = false; CloudTask.UserIdentity = new UserIdentity(new AutoUserSpecification(elevationLevel: ElevationLevel.NonAdmin));
CloudTask.RunElevated nie określono Brak wymaganej aktualizacji

Batch Java

Jeśli kod używa... Zaktualizuj go do....
CloudTask.withRunElevated(true); CloudTask.withUserIdentity(new UserIdentity().withAutoUser(new AutoUserSpecification().withElevationLevel(ElevationLevel.ADMIN));
CloudTask.withRunElevated(false); CloudTask.withUserIdentity(new UserIdentity().withAutoUser(new AutoUserSpecification().withElevationLevel(ElevationLevel.NONADMIN));
CloudTask.withRunElevated nie określono Brak wymaganej aktualizacji

Batch Python

Jeśli kod używa... Zaktualizuj go do....
run_elevated=True user_identity=userGdzie
user = batchmodels.UserIdentity(
     auto_user=batchmodels.AutoUserSpecification(
          elevation_level=batchmodels.ElevationLevel.admin))
run_elevated=False user_identity=userGdzie
user = batchmodels.UserIdentity(
     auto_user=batchmodels.AutoUserSpecification(
          elevation_level=batchmodels.ElevationLevel.non_admin))
run_elevated nie określono Brak wymaganej aktualizacji

Następne kroki