Skip to content
This repository has been archived by the owner on Oct 10, 2023. It is now read-only.

Dynamically assign AD endpoints for Azure, support AzureStack #3162

Open
conzetti opened this issue Aug 18, 2022 · 4 comments · May be fixed by #4587
Open

Dynamically assign AD endpoints for Azure, support AzureStack #3162

conzetti opened this issue Aug 18, 2022 · 4 comments · May be fixed by #4587
Labels
area/lcm Related to Cluster Lifecycle management kind/feature Categorizes issue or PR as related to a new feature provider/azure related to CAPZ provider support

Comments

@conzetti
Copy link

conzetti commented Aug 18, 2022

Describe the feature request
By default, go-autorest allows downstream consumers, such as tanzu-framework to lookup various endpoints. Presently, tanzu-framework explicitly sets the Active Directory endpoints for a subset of Azure clouds (referencing go-autorest) while inadvertently crippling the ability to deploy to AzureStack, which mandates the setting of endpoints via an additional configuration file.

By dynamically assigning the endpoints, rather than defining the endpoints for a subset of clouds, we forgo the need to contain that logic in tanzu-framework. We also could eliminate the constants that represent the proper Azure cloud names (and not their monikers), which are also present in go-autorest. Example: GermanCloud.

The current set of unit tests compare the local Active Directory values in tanzu-framework against go-autorest, so those would ultimately need to be amended or removed if eliminating the additional logic from azure/client.go.

Currently folks that are attempting to build in secret/top-secret regions are incapable of doing so with the Tanzu CLI because of the limitations that have been mentioned here. Those Azure clouds follow the same pattern as AzureStack, which mandates custom endpoints (and thus the ability to supply an Azure configuration file). Supplying a custom configuration file is already a first-class citizen in go-autorest, so changes would simply need to be made to tanzu-framework to support this capability.

Describe alternative(s) you've considered
Several customers have forked tanzu-framework and built a custom CLI to support their POC efforts. Not a reasonable alternative (from a UX perspective) for licensed users, but an alternative nonetheless.

Affected product area (please put an X in all that apply)

  • ( ) APIs
  • ( ) Addons
  • (X) CLI
  • (X) Docs
  • ( ) IAM
  • (X) Installation
  • ( ) Plugin
  • ( ) Security
  • ( ) Test and Release
  • (X) User Experience
  • ( ) Developer Experience

Additional context
Please let me know if this is something that you'd be open to a pull request for.

@conzetti conzetti added kind/feature Categorizes issue or PR as related to a new feature needs-triage Indicates an issue or PR needs to be triaged labels Aug 18, 2022
@github-actions
Copy link

Hey @conzetti! Thanks for opening your first issue. We appreciate your contribution and welcome you to our community! We are glad to have you here and to have your input on Tanzu Framework.

@vuil vuil added area/lcm Related to Cluster Lifecycle management provider/azure related to CAPZ provider support labels Aug 19, 2022
@vuil
Copy link
Contributor

vuil commented Aug 19, 2022

Thanks @conzetti for the issue. So does the change boil down to adding support for the AzureStackCloud and CLI user expecting to supply a configuration file whose location is controlled via the AZURE_ENVIRONMENT_FILEPATH env var?
If you are aware of existing fork where this issue has already be tackled, it might be useful to include it as I am sure it will be helpful when we look to address this issue.

@vuil
Copy link
Contributor

vuil commented Aug 19, 2022

cc @tenczar

@conzetti
Copy link
Author

conzetti commented Aug 22, 2022

@vuil That's pretty much the synopsis. If AzureStackCloud is a first-class citizen in the CLI, and the AD endpoints aren't provided in tanzu-framework, this largely Just Works ™️ . I have a fork, but I need to rebase, and the tests haven't been written (I only removed the failing tests that were no longer relevant when switching to go-autorest for AD endpoint discovery; will add a link to the fork later today.

conzetti added a commit to conzetti/tanzu-framework that referenced this issue Aug 22, 2022
TL;DR
=====
- See vmware-tanzu#3162
- Leverage go-autorest for AD endpoints; open up possibility of using
  AzureStack / custom Azure clouds in doing so
- Needs appropriate test/fake for AzureStack

Detail
======
ddbbbea introduced several constants in
`client.go` that are already defined in `Azure/go-autorest`. This commit
simply relies on the cloud definitions in `Azure/go-autorest` so we can
do the following:
1. Remain DRY
2. Maintain up-to-date values for all cloud endpoints, since Microsoft
   helps maintain that project
3. Open the possibility of additional Azure clouds that are defined
   entirely by configuration file (e.g. `AzureStack`, TS/S regions)

Current shortcomings of this commit:
* Missing appropriate fake for AzureStack
* Doesn't remove all of the constants that are defined (e.g. the
  `PublicCloud` definition is required by `validate.go`, and I wasn't
  certain if we should import something outside of the project for input
  validation of the CLI)
@rajathagasthya rajathagasthya removed the needs-triage Indicates an issue or PR needs to be triaged label Sep 6, 2022
JefeDavis pushed a commit to JefeDavis/tanzu-framework that referenced this issue Apr 20, 2023
by removing the hard-coded maps for Azure environments and
calling the EnvironmentFromName function from the go-autorest/azure
library we can use the existing tools to validate Azure
Environments while also enabling the initial ability to specify custom
endpoints for AzureStackCloud by using the Environment 'AzureStackCloud'
and specifying AZURE_ENVIRONMENT_FILEPATH and providing an
AzureEnvironment json file

Closes Issue vmware-tanzu#3162

Signed-off-by: Jeff Davis <jeffda@vmware.com>
JefeDavis pushed a commit to JefeDavis/tanzu-framework that referenced this issue Apr 20, 2023
remove hard-coded maps for Azure environments and
call EnvironmentFromName function from go-autorest/azure
library to leverage existing tools to validate Azure
Environments also enables initial ability to specify custom
endpoints for AzureStackCloud by using the Environment 'AzureStackCloud'
and specifying AZURE_ENVIRONMENT_FILEPATH and providing an
AzureEnvironment json file

Closes Issue vmware-tanzu#3162

Signed-off-by: Jeff Davis <jeffda@vmware.com>
JefeDavis pushed a commit to JefeDavis/tanzu-framework that referenced this issue Apr 20, 2023
remove hard-coded maps for Azure environments and
call EnvironmentFromName function from go-autorest/azure
library to leverage upstream provider to validate Azure
Environments also enables initial ability to specify custom
endpoints for AzureStackCloud by using the Environment 'AzureStackCloud'
and specifying AZURE_ENVIRONMENT_FILEPATH and providing an
AzureEnvironment json file

Closes Issue vmware-tanzu#3162

Signed-off-by: Jeff Davis <jeffda@vmware.com>
JefeDavis pushed a commit to JefeDavis/tanzu-framework that referenced this issue Apr 21, 2023
remove hard-coded maps for Azure environments and
call EnvironmentFromName function from go-autorest/azure
library to leverage upstream provider to validate Azure
Environments also enables initial ability to specify custom
endpoints for AzureStackCloud by using the Environment 'AzureStackCloud'
and specifying AZURE_ENVIRONMENT_FILEPATH and providing an
AzureEnvironment json file

Closes Issue vmware-tanzu#3162

Signed-off-by: Jeff Davis <jeffda@vmware.com>
JefeDavis pushed a commit to JefeDavis/tanzu-framework that referenced this issue Apr 21, 2023
remove hard-coded maps for Azure environments and
call EnvironmentFromName function from go-autorest/azure
library to leverage upstream provider to validate Azure
Environments also enables initial ability to specify custom
endpoints for AzureStackCloud by using the Environment 'AzureStackCloud'
and specifying AZURE_ENVIRONMENT_FILEPATH and providing an
AzureEnvironment json file

Closes Issue vmware-tanzu#3162

Signed-off-by: Jeff Davis <jeffda@vmware.com>
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
area/lcm Related to Cluster Lifecycle management kind/feature Categorizes issue or PR as related to a new feature provider/azure related to CAPZ provider support
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants