Uploaded image for project: 'OpenShift Bugs'
  1. OpenShift Bugs
  2. OCPBUGS-27237

CPO needs to filter out IAM Role paths when modifying the allowed principals of a VPC Endpoint Service

XMLWordPrintable

    • Moderate
    • No
    • False
    • Hide

      None

      Show
      None

      This is a clone of issue OCPBUGS-23511. The following is the description of the original issue:
      —
      Description of problem:

      When creating an IAM role with a "path" (https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_identifiers.html#identifiers-friendly-names) its "principal" when applied to trust policies or VPC Endpoint Service allowed principals confusingly does not include the path. That is, for the folowing rolesRef on a hostedcluster:

      spec:
  platform:
    aws:
      rolesRef:
        controlPlaneOperatorARN: arn:aws:iam::765374464689:role/adecorte/ad-int-path1-y4y2-kube-system-control-plane-operator
        imageRegistryARN: arn:aws:iam::765374464689:role/adecorte/ad-int-path1-y4y2-openshift-image-registry-installer-cloud-crede
        ingressARN: arn:aws:iam::765374464689:role/adecorte/ad-int-path1-y4y2-openshift-ingress-operator-cloud-credentials
        kubeCloudControllerARN: arn:aws:iam::765374464689:role/adecorte/ad-int-path1-y4y2-kube-system-kube-controller-manager
        networkARN: arn:aws:iam::765374464689:role/adecorte/ad-int-path1-y4y2-openshift-cloud-network-config-controller-clou
        nodePoolManagementARN: arn:aws:iam::765374464689:role/adecorte/ad-int-path1-y4y2-kube-system-capa-controller-manager
        storageARN: arn:aws:iam::765374464689:role/adecorte/ad-int-path1-y4y2-openshift-cluster-csi-drivers-ebs-cloud-creden

      The actual valid principal that should be added to the VPC Endpoint Service's allowed principals is: 

      arn:aws:iam::765374464689:role/ad-int-path1-y4y2-kube-system-control-plane-operator

      instead of

      arn:aws:iam::765374464689:role/adecorte/ad-int-path1-y4y2-kube-system-control-plane-operator

      However, for all other cases, the full ARN including the path should be used, e.g. https://github.com/openshift/hypershift/blob/082e880d0a492a357663d620fa58314a4a477730/hypershift-operator/controllers/hostedcluster/internal/platform/aws/aws.go#L237-L273

      Version-Release number of selected component (if applicable):

      4.14.1

      How reproducible:

      100%

      Steps to Reproduce:

      ROSA HCP-specific steps:
      1. rosa create account-roles --path /anything/ -m auto -y
2. rosa create cluster --hosted-cp
3. ...etc
4a. Observe on the hosted cluster AWS Account that the VPC Endpoint cannot be created with the error: 'failed to create vpc endpoint: InvalidServiceName'
4b. Observe on the management cluster that CPO is failing to update the VPC Endpoint Service's allowed principals with the error: Client.InvalidPrincipal
5. If the contents of .spec.platform.aws.rolesRef.controlPlaneOperatorARN are manually applied to the additional allowed principals with the path component removed, then the problems are largely fixed on the hosted cluster side. VPC Endpoint is created, worker nodes can spin up, etc.

      Actual results:

      The VPC Endpoint Service is attempting and failing to get this applied to its additional allowed principals:

arn:aws:iam::${ACCOUNT_ID}:role/path/name

      Expected results:

      The VPC Endpoint Service gets this applied to its additional allowed principals:

arn:aws:iam::${ACCOUNT_ID}:role/name

      Additional info:

       

            mshen.openshift Michael Shen
            openshift-crt-jira-prow OpenShift Prow Bot
            Jie Zhao Jie Zhao
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Created:
              Updated:
              Resolved: