You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
azure: download nodeup from Blob Storage with curl
When KOPS_BASE_URL is an azureblob://<account>/<container>/<key> URL on
an Azure cluster, the bootstrap script downloads nodeup with curl. It
requests an OAuth token for the system-assigned managed identity from
the instance metadata service and passes the Authorization and
x-ms-version headers to curl through stdin, so the token never reaches
disk, process arguments, or console logs.
The download URL hard-codes the public blob.core.windows.net endpoint,
so validation rejects non-public AZURE_ENVIRONMENT values. Source
locations are percent-escaped and validated when the script is
rendered, so malformed URLs fail during kops update rather than in the
boot retry loop.
spec.assets.fileRepository now accepts an azureblob:// URL on Azure, so
that the node assets can be hosted in the same private container. The
URL must include a container, and nodes on other clouds cannot
authenticate to Azure Blob Storage, so validation keeps rejecting it
there. Nodeup reads these assets through VFS using the managed identity
credentials, and "kops get assets --copy" can now also write to an
azureblob:// repository.
Access is not granted automatically: the docs describe granting Storage
Blob Data Reader on the assets container only, never on the state-store
account, which would let nodes read the cluster PKI.
@@ -80,9 +94,11 @@ You can copy assets into their repositories either by running `kops get assets -
80
94
When running `kops get assets --copy`, kOps copies assets into their respective repositories if
81
95
they do not already exist there.
82
96
83
-
For file assets, kOps only supports copying to a repository that is either an S3 or GCS bucket.
97
+
For file assets, kOps only supports copying to a repository that is an S3 bucket, a GCS bucket,
98
+
or an Azure Blob Storage container.
84
99
An S3 bucket must be configured with a prefix of `s3://` or using the [regional naming conventions of S3](https://docs.aws.amazon.com/general/latest/gr/rande.html#s3_region).
85
100
A GCS bucket must be configured with a prefix of `https://storage.googleapis.com/` or `gs://`.
101
+
An Azure Blob Storage container must be configured with a prefix of `azureblob://`.
Copy file name to clipboardExpand all lines: docs/releases/1.37-NOTES.md
+2Lines changed: 2 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -34,6 +34,8 @@ As part of this removal, the `protokube` component, whose only remaining respons
34
34
35
35
* Private cluster asset repositories now support AWS `s3://` URLs in addition to existing GCE `gs://` URLs, both for `KOPS_BASE_URL` (nodeup download) and `spec.assets.fileRepository`. Nodes authenticate with their instance credentials; see the [asset repository documentation](https://kops.sigs.k8s.io/operations/asset-repository/) for the required permissions. The AWS nodeup download requires node images with curl 8.0 or newer.
36
36
37
+
* Private cluster asset repositories now also support Azure `azureblob://<account>/<container>/<prefix>` URLs, both for `KOPS_BASE_URL` (nodeup download) and `spec.assets.fileRepository`. Nodes authenticate with their system-assigned managed identity, which has to be granted the `Storage Blob Data Reader` role on the assets container; see the [asset repository documentation](https://kops.sigs.k8s.io/operations/asset-repository/) for the details and warnings.
38
+
37
39
# Breaking changes
38
40
39
41
* Support for AWS Classic Load Balancer (CLB) for the API has been removed. Clusters with `spec.api.loadBalancer.class: Classic` (or with no explicit `class`, which previously defaulted to Classic) fail validation, and the long-deprecated `kops create cluster --api-loadbalancer-class` flag has been removed. Existing clusters using a CLB must migrate to a Network Load Balancer (NLB) using kOps 1.36 or earlier before upgrading to kOps 1.37, following the [CLB to NLB migration guide](https://github.com/kubernetes/kops/blob/master/permalinks/acm_nlb.md). Attaching instance groups to externally-managed Classic Load Balancers via `spec.externalLoadBalancers[].loadBalancerName` remains supported.
allErrs=append(allErrs, field.Invalid(fieldPath, s, fmt.Sprintf("s3:// fileRepository is only supported on AWS, but the cloud provider is %q", cloudProvider)))
808
808
}
809
+
case"azureblob":
810
+
// Only Azure instances can authenticate to Azure Blob Storage with their managed identity.
811
+
ifcloudProvider!=kops.CloudProviderAzure {
812
+
allErrs=append(allErrs, field.Invalid(fieldPath, s, fmt.Sprintf("azureblob:// fileRepository is only supported on Azure, but the cloud provider is %q", cloudProvider)))
813
+
}
814
+
// Without a container, each remapped asset would treat its first path segment as the container.
0 commit comments