[BUG]: powerscale.AccessZoneResource unable to add non-file based auth providers.

[petew-nfx]

Bug Description

AccessZoneResource.custom_auth_providers is created by converting the fully qualified name to a short name, by splitting on ":" and taking the second element. Remove entries from custom_auth_providers works, but adding them back fails. This is due to "lsa-file-provider" being hard coded to fully qualify the custom entry. It is also important to remember that the order of auth providers matters, as that determines lookup order.

Resource or DataSource Name

AccessZone

Terraform Version

Terraform 1.6.6

OneFS Version

9.4.0.13

go Version

go 1.21.5

Unisphere Version

N/A

Operating System

MacOS Darwin Kernel Version 23.2.0

Terraform File Used

Initial file

resource "powerscale_accesszone" "test-zone" {
    custom_auth_providers       = [
      "System",
      "AD.DOMAIN.SOMEWHERE.COM",
       ]
    groupnet                    = "test-zone"
    name                        = "test-zone"
    path                        = "/ifs/test"
}

Commented out file

resource "powerscale_accesszone" "test-zone" {
    custom_auth_providers       = [
      "System",
//      "AD.DOMAIN.SOMEWHERE.COM",
       ]
    groupnet                    = "test-zone"
    name                        = "test-zone"
    path                        = "/ifs/test"
}

State

% terraform state show powerscale_accesszone.test-zone
# powerscale_accesszone.test-zone:
resource "powerscale_accesszone" "test-zone" {
    alternate_system_provider   = "lsa-file-provider:MinimumRequired"
    auth_providers              = [
        "lsa-local-provider:System",
        "lsa-activedirectory-provider:AD.DOMAIN.SOMEWHERE.COM",
        "lsa-local-provider:test-zone",
    ]
    cache_entry_expiry          = 14400
    custom_auth_providers       = [
        "System",
        "AD.DOMAIN.SOMEWHERE.COM",
    ]
    groupnet                    = "test-zone"
    home_directory_umask        = 63
    id                          = "test-zone"
    ifs_restricted              = []
    name                        = "test-zone"
    negative_cache_entry_expiry = 60
    path                        = "/ifs/studio"
    skeleton_directory          = "/usr/share/skel"
    system                      = false
    system_provider             = "lsa-file-provider:System"
    user_mapping_rules          = []
    zone_id                     = 2
}

Logs

% 
% terraform apply
...
powerscale_accesszone.test-zone: Modifying... [id=test-zone]
╷
│ Error: Error editing access zone
│
│   with powerscale_accesszone.test-zone,
│   on zone_test-zone.tf line 2, in resource "powerscale_accesszone" "test-zone":
│    2: resource "powerscale_accesszone" "test-zone" {
│
│ Could not update access zones with error: Auth provider "lsa-file-provider:AD.DOMAIN.SOMEWHERE.COM" does not exist.:
│ No such file or directory  404 Not Found

Steps to Reproduce

• Import an AccessZone with an additional auth provider that is not file based.
• Comment out this additional provider.
• Run terraform apply to remove on the cluster.
• Uncomment the provider.
• Run terraform apply to add back to the cluster.

Expected Behavior

Auth providers defined on the cluster should be able to be added/removed from an AccessZone via terraform apply.

Actual Behavior

Auth providers defined on the cluster can be removed from an AccessZone, but can only be added if they are an lsa-file-provider

Screenshots

No response

Additional Information

No response

[taohe1012]

hi @petew-nfx , thankns for reporting the access zone issues. I'm clear about the first issue - unable to add non-file based auth providers, and will solve it in our plan. And for the order of auth providers matters, you mean the order of auth_providers should be same to custom_auth_providers ?

[petew-nfx]

In regards to auth_providers I was emphasizing the point made in the PowerScale OneFS CLI Administration Guide: The order in which authentication providers are added to access zone designates the order in which providers are searched during authentication and user lookup.

The custom_auth_providers is missing the lsa-local-provider: entry - which results in the inability to set where it sits in the order.

[taohe1012]

hi @petew-nfx , according to the doc, the custom_auth_providersis used for adding or removing auth_providers to the access zone, the access zone also has one filed auth_providersto specifies the list of authentication providers available on this access zone, and we can focus on its order.

[petew-nfx]

auth_providers is a read-only attribute which prevents using it in a tf file. custom_auth_providers is derived from auth_providers

[taohe1012]

hi @petew-nfx , the code you pointed to is only used in import function; in create and update function, we use custom_auth_providers to modify auth providers, not derived from auth_providers. And custom_auth_providers order is decided by user.

[petew-nfx]

Yes, the code I pointed to showed how custom_auth_providers is derived from auth_providers by removing the "main" provider (based on zone name). If the custom_auth_providers lacks the zone provider, it cannot be used for arbitrary ordering of providers. Is there a reason for not using auth_providers directly?

[taohe1012]

hi @petew-nfx . yes, the the custom_auth_providers is used to overcome the limitation on the PowerScale API due to the automatic local-provider being created that we cannot order the automatically created provider. Since sending that in the PUT or POST request adds a failure. And you can still be able to order the other providers using the custom provider.

[petew-nfx]

Passing the local-provider does not result in failure. In fact isi zone zones modify <zone-name> --auth-providers=<provider-list> requires a full list of providers, including the local-provider for the zone. Passing --debug to the command shows that a PUT to 3/zones/<zone-name> with the local-provider succeeds. Going through all possible permutations of the provides order shows there is no restriction on ordering.

[taohe1012]

@petew-nfx To order providers, In custom_auth_providers, you can input your all providers including the automatic local-provider for the zone. Some user may not input the automatic local-provider to provider list, if we merge custom_auth_providers and auth_providers to one, this may result to terraform state mismatch and throw exception. And if need more detailed information, if possible, we may schedule a meeting to discuss this issue through zoom or other ways. Thanks.

[petew-nfx]

It seems the use of custom_auth_providers is unnecessary . If all entries are to be supplied and also in order, then auth_providers could be used. Ensuring the existence of lsa-local-provider:<zone> in the list chould be a validation step.

[taohe1012]

hi @petew-nfx , if user input["lsa-local-provider:System"] to auth_providers, the response should be["lsa-local-provider:System", ""lsa-local-provider:yourAutomaticProvider], this will result to the planed value are mismatched to the response state and the terraform will report exception. So it's useful to use custom_auth_providersfor input separately.

[forrestxia]

Close per PR 127 merged.