Zrozumienie różnic platformowych w obciążeniu przepływu pracy opartego na zdarzeniach (EDW)

Przed zreplikowanie obciążenia EDW na platformie Azure upewnij się, że masz solidną wiedzę na temat różnic operacyjnych między platformami AWS i Azure.

W tym artykule przedstawiono niektóre kluczowe pojęcia dotyczące tego obciążenia i linki do zasobów, aby uzyskać więcej informacji.

Zarządzanie tożsamościami i dostępem

Obciążenie AWS EDW używa roli zarządzania tożsamościami i dostępem (IAM) platformy AWS, która jest przyjmowana przez usługę EKS. Ta rola jest przypisywana do zasobników EKS w celu zezwolenia na dostęp do zasobów platformy AWS, takich jak kolejki lub bazy danych, bez konieczności przechowywania poświadczeń.

Platforma Azure implementuje kontrolę dostępu opartą na rolach (RBAC) inaczej niż aws. Na platformie Azure przypisania ról są skojarzone z jednostką zabezpieczeń (użytkownikiem, grupą, tożsamością zarządzaną lub jednostką usługi), a jednostka zabezpieczeń jest skojarzona z zasobem.

Uwierzytelnianie między usługami

Obciążenie AWS EDW używa komunikacji między usługami w celu nawiązania połączenia z kolejką i bazą danych. Usługa AWS EKS używa AssumeRole, funkcji IAM, do uzyskania tymczasowych poświadczeń zabezpieczeń, aby uzyskać dostęp do użytkowników, aplikacji lub usług platformy AWS. Ta implementacja umożliwia usługom przyjęcie roli IAM, która zapewnia określony dostęp, oferując bezpieczne i ograniczone uprawnienia między usługami.

W przypadku dostępu do usługi kolejki prostej Amazon Simple Queue Service (SQS) i bazy danych Amazon DynamoDB za pomocą komunikacji usługowej, platforma AWS stosuje AssumeRole z EKS, co jest implementacją projekcji woluminu tokenu konta usługi Kubernetes. W obciążeniu EKS EDW konfiguracja pozwala na to, aby konto usługi Kubernetes przyjęło rolę AWS Identity and Access Management (IAM). Zasobniki skonfigurowane do korzystania z konta usługi mogą następnie uzyskiwać dostęp do dowolnej usługi AWS, do której rola ma uprawnienia. W obciążeniu EDW zdefiniowano dwie zasady IAM w celu nadania uprawnień dostępu do usług Amazon DynamoDB i Amazon SQS.

Za pomocą usługi AKS możesz użyć Microsoft Entra Managed Identity z Microsoft Entra Workload ID.

Tożsamość zarządzana przypisana przez użytkownika jest tworzona i jest jej nadawany dostęp do tabeli usługi Azure Storage przez przypisanie jej roli Współautora danych tabeli magazynu. Tożsamości zarządzanej przyznano również dostęp do kolejki usługi Azure Storage poprzez przypisanie jej roli Współautora danych kolejki usługi Azure Storage. Te przypisania ról są ograniczone do określonych zasobów, co umożliwia tożsamości zarządzanej odczytywanie komunikatów w określonej kolejce usługi Azure Storage i zapisywanie ich w określonej tabeli usługi Azure Storage. Tożsamość zarządzana jest następnie mapowana na tożsamość obciążenia Kubernetes, która zostanie skojarzona z tożsamością zasobników, w których są wdrażane kontenery aplikacji. Aby uzyskać więcej informacji, zobacz Używanie tożsamości obciążeń Microsoft Entra z AKS.

Po stronie klienta zestawy SDK platformy Azure w języku Python obsługują przezroczyste sposoby korzystania z kontekstu tożsamości obciążenia, co eliminuje potrzebę jawnego uwierzytelniania przez dewelopera. Kod działający w przestrzeni nazw/zasobniku w usłudze AKS z ustanowioną tożsamością obciążenia może uwierzytelniać się w usługach zewnętrznych przy użyciu zamapowanej tożsamości zarządzanej.

Zasoby

Następujące zasoby mogą pomóc dowiedzieć się więcej o różnicach między platformami AWS i Azure dla technologii używanych w obciążeniu EDW:

Następne kroki

Współautorzy

Firma Microsoft utrzymuje ten artykuł. Następujący współautorzy pierwotnie to napisali:

• Ken Kilty | Główny Kierownik Techniczny ds. Programu
• Russell de Pina | Główny TPM
• Jenny Hayes | Starszy deweloper zawartości
• Carol Smith | Starszy deweloper zawartości
• Erin Schaffer | Content Developer 2