Sécurité de l'infrastructure dans ROSA - Red Hat OpenShift Service on AWS

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Sécurité de l'infrastructure dans ROSA

En tant que service géré, Red Hat OpenShift Service on AWS il est protégé par la sécurité du réseau AWS mondial. Pour plus d'informations sur les services AWS de sécurité et sur la manière dont AWS l'infrastructure est protégée, consultez la section Sécurité du AWS cloud. Pour concevoir votre AWS environnement en utilisant les meilleures pratiques en matière de sécurité de l'infrastructure, voir Protection de l'infrastructure dans Security Pillar — AWS Well-Architected Framework.

Vous utilisez des appels d'API AWS publiés pour accéder ROSA via le AWS réseau. Les clients doivent prendre en charge les éléments suivants :

  • Protocole TLS (Transport Layer Security). Nous exigeons TLS 1.2 et recommandons TLS 1.3.

  • Ses suites de chiffrement PFS (Perfect Forward Secrecy) comme DHE (Ephemeral Diffie-Hellman) ou ECDHE (Elliptic Curve Ephemeral Diffie-Hellman). La plupart des systèmes modernes tels que Java 7 et les versions ultérieures prennent en charge ces modes.

En outre, les demandes doivent être signées à l’aide d’un ID de clé d’accès et d’une clé d’accès secrète associée à un principal IAM. Vous pouvez également utiliser AWS Security Token Service (AWS STS) pour générer des informations d’identification de sécurité temporaires et signer les demandes.

Isolation du réseau en cluster

Les ingénieurs de fiabilité des sites Red Hat (SREs) sont responsables de la gestion continue et de la sécurité réseau du cluster et de la plate-forme d'application sous-jacente. Pour plus d'informations sur les responsabilités de Red Hat en matière de ROSA, consultezVue d'ensemble des responsabilités pour ROSA.

Lorsque vous créez un nouveau cluster, ROSA vous avez la possibilité de créer un point de terminaison et des routes d'application du serveur d'API Kubernetes public ou un point de terminaison d'API Kubernetes privé et des routes d'application. Cette connexion est utilisée pour communiquer avec votre cluster (à l'aide d'outils OpenShift de gestion tels que les CLI et OpenShift CLI ROSA). Une connexion privée permet à toutes les communications entre vos nœuds et le serveur d'API de rester au sein de votre VPC. Si vous activez l'accès privé au serveur d'API et aux routes d'application, vous devez utiliser un VPC existant et AWS PrivateLink connecter le VPC au service principal. OpenShift

L'accès au serveur d'API Kubernetes est sécurisé à l'aide d'une combinaison de AWS Identity and Access Management (IAM) et d'un contrôle d'accès basé sur les rôles (RBAC) Kubernetes natif. Pour plus d'informations sur Kubernetes RBAC, consultez la section Utilisation de l'autorisation RBAC dans la documentation de Kubernetes.

ROSA vous permet de créer des itinéraires d'application sécurisés à l'aide de plusieurs types de terminaison TLS pour délivrer des certificats au client. Pour plus d'informations, consultez la section Routes sécurisées dans la documentation Red Hat.

Si vous créez un ROSA cluster dans un VPC existant, vous spécifiez les sous-réseaux VPC et les zones de disponibilité que votre cluster doit utiliser. Vous définissez également les plages d'adresses CIDR que le réseau de clusters doit utiliser et vous associez ces plages d'adresses CIDR aux sous-réseaux VPC. Pour plus d'informations, consultez les définitions des plages CIDR dans la documentation Red Hat.

Pour les clusters qui utilisent le point de terminaison d'API public, votre VPC ROSA doit être configuré avec un sous-réseau public et privé pour chaque zone de disponibilité dans laquelle vous souhaitez déployer le cluster. Pour les clusters qui utilisent le point de terminaison d'API privé, seuls les sous-réseaux privés sont requis.

Si vous utilisez un VPC existant, vous pouvez configurer vos ROSA clusters pour qu'ils utilisent un serveur proxy HTTP ou HTTPS pendant ou après la création du cluster afin de chiffrer le trafic Web du cluster, ajoutant ainsi un niveau de sécurité supplémentaire à vos données. Lorsque vous activez un proxy, l'accès direct à Internet est refusé aux composants principaux du cluster. Le proxy ne refuse pas l'accès à Internet aux charges de travail des utilisateurs. Pour plus d'informations, consultez la section Configuration d'un proxy à l'échelle du cluster dans la documentation Red Hat.

Isolation du réseau de pods

Si vous êtes administrateur de cluster, vous pouvez définir des politiques réseau au niveau du pod qui limitent le trafic aux pods de votre ROSA cluster.