In a recent support exchange with Microsoft regarding a malfunctioning AKS cluster, we discovered that I had inadvertently broken some assumptions for the DNS prefix (it contained periods, which broke HTTPS certificate validation down the line). After verifying that recreating the cluster with a valid DNS prefix worked, I set out to ensure I don't make the same mistake again (and that nobody else does either).
Looking at the portal, the following validation rules are listed:
Attempting to fix that in Terraform (which we use for configurating and provisioning), I submitted a PR which used the following RegEx to comply to those rules:
^[a-zA-Z][-a-zA-Z0-9]{0,43}[a-zA-Z0-9]$
However, in the continued conversation with the MS Support tech, I was told that the next version of the CLI will validate this correctly, due to the following change (screenshotted from an internal repo; since it is golang I have no idea how it relates to the CLI):
This is the new regex used according to that screenshot:
^ # start of string
( # start of group
[a-zA-Z0-9] # any alphanumeric character
| # or
[a-zA-Z0-9] # any alphanumeric character
[a-zA-Z0-9\-]* # any alphanumeric character or hyphen, 0 or more times
[a-zA-Z0-9] # any alphanumeric character
) # end of group
* # repeat group 0 or more times
$ # end of string
There are a number of strings that pass validation here, but shouldn't pass according to validation in the portal. For example:
"fo" (too short according to portal, OK according to regex)
"foo-bar-baz-andgoingonforaverylongtimesowegetmorethan45chars" (too long according to portal, OK according to regex)
"" (the empty string; too short according to portal, OK according to regex)
"123foo" (starts with a number, still OK according to regex)
...and I'm sure there are others as well.
In order to get the validation right in Terraform, I'd like to verify what the exact validation rules should be, and ensure that we use the same rules on all UI surfaces.
In a recent support exchange with Microsoft regarding a malfunctioning AKS cluster, we discovered that I had inadvertently broken some assumptions for the DNS prefix (it contained periods, which broke HTTPS certificate validation down the line). After verifying that recreating the cluster with a valid DNS prefix worked, I set out to ensure I don't make the same mistake again (and that nobody else does either).
Looking at the portal, the following validation rules are listed: Attempting to fix that in Terraform (which we use for configurating and provisioning), I submitted a PR which used the following RegEx to comply to those rules:
However, in the continued conversation with the MS Support tech, I was told that the next version of the CLI will validate this correctly, due to the following change (screenshotted from an internal repo; since it is golang I have no idea how it relates to the CLI):
This is the new regex used according to that screenshot:
There are a number of strings that pass validation here, but shouldn't pass according to validation in the portal. For example:
"fo"
(too short according to portal, OK according to regex)"foo-bar-baz-andgoingonforaverylongtimesowegetmorethan45chars"
(too long according to portal, OK according to regex)""
(the empty string; too short according to portal, OK according to regex)"123foo"
(starts with a number, still OK according to regex)...and I'm sure there are others as well.
In order to get the validation right in Terraform, I'd like to verify what the exact validation rules should be, and ensure that we use the same rules on all UI surfaces.