Fix up ContainerRegistry Authentication for OCI

[jborean93]

PR Summary

Updates the ContainerRegistry authentication logic to work with OCI compliant registries like ghcr.io. The changes skip using the Azure environment credentials unless the bearer service ends with .azurecr.io as these tokens are only useful for ACR. The Azure AccessToken to Bearer token exchange is also simplified with an unecessary step removed.

A new special prefix is used for the username when a credential represents an Azure AccessToken. This is necessary to ensure that only these specific types of credentials will use the Azure specific steps for authentication.

While this new prefix is technically a breaking change, it isn't documented and seems like it's mostly added for testing. With the new change it is now possible to use a credential that contains the Azure app client id and client secret which was not possible before. I'm happy to talk through this more but it is important that this is fixed before too many people rely on the existing behaviour.

PR Context

Fixes: #1946

PR Checklist

• PR has a meaningful title
  • Use the present tense and imperative mood when describing your changes
• Summarized changes
• Make sure all .h, .cpp, .cs, .ps1 and .psm1 files have the correct copyright header
• This PR is ready to merge and is not Work in Progress.
  • If the PR is work in progress, please add the prefix WIP: or [ WIP ] to the beginning of the title (the WIP bot will keep its status check at Pending while the prefix is present) and remove the prefix when the PR is ready.
• Breaking changes
  • None
  • OR
  • Documentation needed
    • Issue filed:
• User-facing changes
  • Not Applicable
  • OR
  • Documentation needed
    • Issue filed:
• Testing - New and feature
  • N/A or can only be tested interactively
  • OR
  • Make sure you've added a new test if existing tests do not effectively test the code changed
• Tooling
  • I have considered the user experience from a tooling perspective and don't believe tooling will be impacted.
  • OR
  • I have considered the user experience from a tooling perspective and enumerated concerns in the summary.

[adityapatwardhan]

@jborean93 thank you for the PR. I am going to have a look at this shortly.

[adityapatwardhan]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[anamnavi]

@jborean93 sorry for the delay getting back to you, but the team spent some time looking at the code today. Can you confirm if you're able to find a package from a Github Container Registry with these changes, and if so please share the steps used.

We've created a Github Container registry, with URL: https://ghcr.io/powershell and published OCI artifact microsoft.powershell.psresourceget there and it is publicly accessible for you to test against. Let me know if you run into any issues with access.

When finding a package from Github container registry, we get a 404 error:

Set-Secret -Name "gh-testcred" -Secret <gh_PAT_with_packagesRead> -Verbose
$ghPSCredInfo = New-Object Microsoft.PowerShell.PSResourceGet.UtilClasses.PSCredentialInfo ("SecretStore", "gh-testcred")
Register-PSResourceRepository -Name "gh-psrg" -ApiVersion 'ContainerRegistry' -Uri "https://ghcr.io/powershell" -CredentialInfo $ghPSCredInfo -Verbose

Find-PSResource -Name 'microsoft.powershell.psresourceget' -Repository gh-psrg -Verbose -Debug
DEBUG: Filtering package name(s) on wildcards
DEBUG: In FindHelper::FindByResourceName()
DEBUG: Parameters passed in >>> Name: 'microsoft.powershell.psresourceget'; ResourceType: 'None'; VersionRange: ''; NuGetVersion: ''; VersionType: 'NoVersion'; Version: ''; Prerelease: 'False'; Tag: ''; Repository: 'gh-psrg'; IncludeDependencies 'False'
VERBOSE: Setting Secret Management network credentials
VERBOSE: credential successfully read from vault and set for repository: gh-psrg
DEBUG: Searching through repository 'gh-psrg'
DEBUG: In FindHelper::SearchByNames()
DEBUG: No version specified, package name is specified
DEBUG: In ContainerRegistryServerAPICalls::FindName()
DEBUG: In ContainerRegistryServerAPICalls::FindPackagesWithVersionHelper()
DEBUG: In ContainerRegistryServerAPICalls::GetContainerRegistryAccessToken()
DEBUG: In ContainerRegistryServerAPICalls::TryGetContainerRegistryTokenBearerRealm()
VERBOSE: Failed to get Repository bearer realm
Find-PSResource: Response status code does not indicate success: 404 (Not Found).

We also tested Find-PSResource against our Azure Container Registry, and get a different error:

$azt = Get-AzAccessToken
$tokenId = $azt.TenantId
Set-Secret -Name "AzureAccessToken: $tenantId" -Secret $azt.Token -Verbose
$psCredInfo = New-Object Microsoft.PowerShell.PSResourceGet.UtilClasses.PSCredentialInfo ("SecretStore", "AzureAccessToken: $tenantId")
Register-PSResourceRepository -Name $ACRRepoName -ApiVersion 'ContainerRegistry' -Uri $ACRRepoUri -CredentialInfo $psCredInfo -Verbose

Find-PSResource -Name $testModuleName -Repository $ACRRepoName -Debug -Verbose
DEBUG: Filtering package name(s) on wildcards
DEBUG: In FindHelper::FindByResourceName()
DEBUG: Parameters passed in >>> Name: 'test-module'; ResourceType: 'None'; VersionRange: ''; NuGetVersion: ''; VersionType: 'NoVersion'; Version: ''; Prerelease: 'False'; Tag: ''; Repository: 'ACRRepo'; IncludeDependencies 'False'
VERBOSE: Setting Secret Management network credentials
VERBOSE: credential successfully read from vault and set for repository: ACRRepo
DEBUG: Searching through repository 'ACRRepo'
DEBUG: In FindHelper::SearchByNames()
DEBUG: No version specified, package name is specified
DEBUG: In ContainerRegistryServerAPICalls::FindName()
DEBUG: In ContainerRegistryServerAPICalls::FindPackagesWithVersionHelper()
DEBUG: In ContainerRegistryServerAPICalls::GetContainerRegistryAccessToken()
DEBUG: In ContainerRegistryServerAPICalls::TryGetContainerRegistryTokenBearerRealm()
DEBUG: In ContainerRegistryServerAPICalls::GetRegistryCredential()
DEBUG: In ContainerRegistryServerAPICalls::GetHttpResponseJObjectUsingDefaultHeaders()
Find-PSResource: The format of value 'Basic <token details here>' is invalid.