secret ARN validation warning

[blakemertz]

I'm trying to generate a cluster with 1) microsoft active directory for multiple users and 2) shared EFS partition for convenience of storing big data to our virtual drive. I have managed to accomplish #2, and also have managed to create a microsoft AD. However, when I did a dry run in the ParallelCluster UI, I get the following warning:

ValidationWarnings:
PasswordSecretArnValidator: Cannot validate secret arn:aws:secretsmanager:us-east-1:XXXXXXXXXXXX:secret:PasswordSecret-modulus-AD-XXXXXX due to lack of permissions. Please refer to ParallelCluster official documentation for more information.

I will still be able to create the cluster, but I want to know where I can properly locate my secret ARN for the microsoft AD? I thought I had properly copied it from my cloud formation console: but then I wouldn't be getting that validation warning, correct? Is there a different ARN that I should be referencing? The only other possibility I can see is DomainCertificateSecretArn or DomainCertificateSecretReadPolicy.

Below is my configuration script:

HeadNode:
  InstanceType: c5.2xlarge
  Networking:
    SubnetId: subnet-xxxxxxxx
    AdditionalSecurityGroups:
      - sg-xxxxxxxx
  Ssh:
    KeyName: mertz_key
  LocalStorage:
    RootVolume:
      VolumeType: gp3
  Iam:
    AdditionalIamPolicies:
      - Policy: arn:aws:iam::aws:policy/AmazonSSMManagedInstanceCore
Scheduling:
  Scheduler: slurm
  SlurmQueues:
    - Name: modbind
      AllocationStrategy: lowest-price
      ComputeResources:
        - Name: modbind
          Instances:
            - InstanceType: g4dn.metal
          MinCount: 0
          MaxCount: 10
          DisableSimultaneousMultithreading: true
          Efa:
            Enabled: true
      Networking:
        SubnetIds:
          - subnet-xxxxxxxx
        PlacementGroup:
          Enabled: true
        AdditionalSecurityGroups:
          - sg-xxxxxxxx
      ComputeSettings:
        LocalStorage:
          RootVolume:
            VolumeType: gp3
      CustomActions:
        OnNodeConfigured:
          Script: >-
            s3://parallelcluster-10552b48cfa2e9aa-v1-do-not-delete/modbind-cluster-setup.sh
    - Name: spot
      AllocationStrategy: lowest-price
      ComputeResources:
        - Name: spot
          Instances:
            - InstanceType: g4dn.metal
          MinCount: 0
          MaxCount: 10
          DisableSimultaneousMultithreading: true
          Efa:
            Enabled: true
      ComputeSettings:
        LocalStorage:
          RootVolume:
            VolumeType: gp3
      CapacityType: SPOT
      Networking:
        SubnetIds:
          - subnet-xxxxxxx
        PlacementGroup:
          Enabled: true
        AdditionalSecurityGroups:
          - sg-xxxxxxx
      CustomActions:
        OnNodeConfigured:
          Script: >-
            s3://parallelcluster-10552b48cfa2e9aa-v1-do-not-delete/modbind-cluster-setup.sh
  SlurmSettings: {}
Region: us-east-1
Image:
  Os: centos7
DirectoryService:
  DomainName: modulus.ad.com
  DomainAddr: ldaps://modulus.ad.com
  PasswordSecretArn: >-
    arn:aws:secretsmanager:us-east-1:xxxxxxxxxxxx:secret:PasswordSecret-modulus-AD-xxxxxx
  DomainReadOnlyUser: cn=ReadOnlyUser,ou=Users,ou=MODULUS,dc=modulus,dc=ad,dc=com
SharedStorage:
  - Name: Efs0
    StorageType: Efs
    MountDir: /shared
    EfsSettings:
      FileSystemId: fs-xxxxxxxx

[dreambeyondorange]

Can you confirm that the role you are using to run the UI has permissions to read the secrets? See the example Base AWS ParallelCluster pcluster user policy section in https://docs.aws.amazon.com/parallelcluster/latest/ug/iam-roles-in-parallelcluster-v3.html

[enrico-usai]

Hi @blakemertz

the PasswordSecretArnValidator is executed on the CLI side, so as suggested by Ryan probably the role you're using for the CLI doesn't have the permissions to read that secret. Anyway this is not an issue by itself, the CLI is unable to validate it but this doesn't mean that it is wrong, indeed this is a WARNING and not an ERROR.

The important part is that the Role associated to the head node instance has the permission to read that secret. If your cluster is created correctly this is the case.

If the cluster creation fails you can think to add additional IAM policies, through AdditionalIamPolicies parameter.

Enrico

[github-actions[bot]]

This issue has been automatically closed because there has been no response to our request for more information from the original author. With only the information that is currently in the issue, we don't have enough information to take action. Please reach out if you have or find the answers we need so that we can investigate further.