Fix private hub by zhaoqizqwang · Pull Request #6036 · aws/sagemaker-python-sdk

zhaoqizqwang · 2026-07-16T20:21:47Z

In _build_for_jumpstart() (model_builder_servers.py), after calling get_init_kwargs(hub_arn=...), the returned model_reference_arn is never copied to self.model_reference_arn. It stays None.

When _prepare_container_def_base() later builds the CreateModel container definition, it reads self.model_reference_arn → None, so no HubAccessConfig is attached to the S3DataSource. Without HubAccessConfig, SageMaker cannot broker artifact access through the private hub and falls back to direct S3 access on jumpstart-cache-prod-* → AccessDenied.

…ight validation Split ecr_policy statements in training, serving, and hyperpod role types so that only ecr:GetAuthorizationToken (account-level) remains under Resource: "*". The repository-level actions (BatchGetImage, GetDownloadUrlForLayer, BatchCheckLayerAvailability) are now scoped to arn:aws:ecr:*:*:repository/*, which excludes them from _get_smoke_test_actions. This prevents SimulatePrincipalPolicy from returning implicitDeny for roles that correctly scope ECR permissions to specific repo ARNs (least privilege), fixing the regression that blocked deploys/training/pipelines for those customers.

_build_for_jumpstart calls get_init_kwargs which resolves model_reference_arn for private hub model references, but never copies it back to self.model_reference_arn. This causes _prepare_container_def_base to omit HubAccessConfig from the CreateModel container definition, making SageMaker fall back to direct S3 access on jumpstart-cache-prod-* and fail with AccessDenied.

Upstream aws#6036 independently fixed the model_reference_arn propagation (Defect A) with the same 6-line fix. Resolution: kept upstream's propagation block as canonical (removed our duplicate at the earlier location), kept our hub_content_name lookup fix (Defect B, not covered upstream), and kept our unit test file as the superset (upstream's 2 tests assert a subset of our TestModelReferenceArnPropagation). Verified post-merge: 17/17 unit tests pass, single propagation block, no conflict markers.

…6039) * fix(serve): support aliased hub content names in private hub deploys CreateHubContentReference accepts a custom HubContentName, but the SDK always looks up hub content by model_id, so a reference named differently from the public model id fails with ResourceNotFound. Add optional hub_content_name to JumpStartConfig and thread it through from_jumpstart_config; when set, _build_for_jumpstart resolves hub content by the reference's actual name. Verified E2E against a live private hub with an execution role that has zero S3 permissions: an aliased ModelReference now deploys successfully with SageMaker brokering artifact access through the hub content reference. * test(serve): private hub regression coverage for HubAccessConfig and aliased names Unit tests (extends the #5985 file, shared setup hoisted to a module-level _build_jumpstart_builder helper per package convention): - model_reference_arn propagation regression test guarding the #6036 fix (supersedes the subset assertions added there) - CreateModel payload chain test: drives the real unmocked path _build_for_jumpstart -> _prepare_container_def_base and asserts the container definition carries S3DataSource.HubAccessConfig.HubContentArn for hub builds and omits it for public builds -- the assertion that would have caught the v3.15.1-v3.16.0 regression - hub_content_name lookup and config threading tests Integration tests (slow_test, self-provisioning with full teardown): - test_deploy_with_no_s3_execution_role: zero-S3 execution role deploy, asserts HubAccessConfig on the created Model (service-side contract) - test_deploy_with_aliased_hub_content_name: aliased reference deploy Verified red->green at every layer: 4 unit tests and both integ tests fail on v3.16.0 baseline; all pass with the fixes (integ verified live in us-east-1 with a real hub, zero-S3 role, 2 passed in 38s). --------- Co-authored-by: Eli Davidson <elleedee@amazon.com>

zhaoqizqwang · 2026-07-16T20:21:47Z

In _build_for_jumpstart() (model_builder_servers.py), after calling get_init_kwargs(hub_arn=...), the returned model_reference_arn is never copied to self.model_reference_arn. It stays None.

When _prepare_container_def_base() later builds the CreateModel container definition, it reads self.model_reference_arn → None, so no HubAccessConfig is attached to the S3DataSource. Without HubAccessConfig, SageMaker cannot broker artifact access through the private hub and falls back to direct S3 access on jumpstart-cache-prod-* → AccessDenied.

…ight validation Split ecr_policy statements in training, serving, and hyperpod role types so that only ecr:GetAuthorizationToken (account-level) remains under Resource: "*". The repository-level actions (BatchGetImage, GetDownloadUrlForLayer, BatchCheckLayerAvailability) are now scoped to arn:aws:ecr:*:*:repository/*, which excludes them from _get_smoke_test_actions. This prevents SimulatePrincipalPolicy from returning implicitDeny for roles that correctly scope ECR permissions to specific repo ARNs (least privilege), fixing the regression that blocked deploys/training/pipelines for those customers.

_build_for_jumpstart calls get_init_kwargs which resolves model_reference_arn for private hub model references, but never copies it back to self.model_reference_arn. This causes _prepare_container_def_base to omit HubAccessConfig from the CreateModel container definition, making SageMaker fall back to direct S3 access on jumpstart-cache-prod-* and fail with AccessDenied.

Upstream aws#6036 independently fixed the model_reference_arn propagation (Defect A) with the same 6-line fix. Resolution: kept upstream's propagation block as canonical (removed our duplicate at the earlier location), kept our hub_content_name lookup fix (Defect B, not covered upstream), and kept our unit test file as the superset (upstream's 2 tests assert a subset of our TestModelReferenceArnPropagation). Verified post-merge: 17/17 unit tests pass, single propagation block, no conflict markers.

…6039) * fix(serve): support aliased hub content names in private hub deploys CreateHubContentReference accepts a custom HubContentName, but the SDK always looks up hub content by model_id, so a reference named differently from the public model id fails with ResourceNotFound. Add optional hub_content_name to JumpStartConfig and thread it through from_jumpstart_config; when set, _build_for_jumpstart resolves hub content by the reference's actual name. Verified E2E against a live private hub with an execution role that has zero S3 permissions: an aliased ModelReference now deploys successfully with SageMaker brokering artifact access through the hub content reference. * test(serve): private hub regression coverage for HubAccessConfig and aliased names Unit tests (extends the #5985 file, shared setup hoisted to a module-level _build_jumpstart_builder helper per package convention): - model_reference_arn propagation regression test guarding the #6036 fix (supersedes the subset assertions added there) - CreateModel payload chain test: drives the real unmocked path _build_for_jumpstart -> _prepare_container_def_base and asserts the container definition carries S3DataSource.HubAccessConfig.HubContentArn for hub builds and omits it for public builds -- the assertion that would have caught the v3.15.1-v3.16.0 regression - hub_content_name lookup and config threading tests Integration tests (slow_test, self-provisioning with full teardown): - test_deploy_with_no_s3_execution_role: zero-S3 execution role deploy, asserts HubAccessConfig on the created Model (service-side contract) - test_deploy_with_aliased_hub_content_name: aliased reference deploy Verified red->green at every layer: 4 unit tests and both integ tests fail on v3.16.0 baseline; all pass with the fixes (integ verified live in us-east-1 with a real hub, zero-S3 role, 2 passed in 38s). --------- Co-authored-by: Eli Davidson <elleedee@amazon.com>

zhaoqizqwang · 2026-07-16T20:21:47Z

In _build_for_jumpstart() (model_builder_servers.py), after calling get_init_kwargs(hub_arn=...), the returned model_reference_arn is never copied to self.model_reference_arn. It stays None.

When _prepare_container_def_base() later builds the CreateModel container definition, it reads self.model_reference_arn → None, so no HubAccessConfig is attached to the S3DataSource. Without HubAccessConfig, SageMaker cannot broker artifact access through the private hub and falls back to direct S3 access on jumpstart-cache-prod-* → AccessDenied.

…ight validation Split ecr_policy statements in training, serving, and hyperpod role types so that only ecr:GetAuthorizationToken (account-level) remains under Resource: "*". The repository-level actions (BatchGetImage, GetDownloadUrlForLayer, BatchCheckLayerAvailability) are now scoped to arn:aws:ecr:*:*:repository/*, which excludes them from _get_smoke_test_actions. This prevents SimulatePrincipalPolicy from returning implicitDeny for roles that correctly scope ECR permissions to specific repo ARNs (least privilege), fixing the regression that blocked deploys/training/pipelines for those customers.

_build_for_jumpstart calls get_init_kwargs which resolves model_reference_arn for private hub model references, but never copies it back to self.model_reference_arn. This causes _prepare_container_def_base to omit HubAccessConfig from the CreateModel container definition, making SageMaker fall back to direct S3 access on jumpstart-cache-prod-* and fail with AccessDenied.

Upstream aws#6036 independently fixed the model_reference_arn propagation (Defect A) with the same 6-line fix. Resolution: kept upstream's propagation block as canonical (removed our duplicate at the earlier location), kept our hub_content_name lookup fix (Defect B, not covered upstream), and kept our unit test file as the superset (upstream's 2 tests assert a subset of our TestModelReferenceArnPropagation). Verified post-merge: 17/17 unit tests pass, single propagation block, no conflict markers.

…6039) * fix(serve): support aliased hub content names in private hub deploys CreateHubContentReference accepts a custom HubContentName, but the SDK always looks up hub content by model_id, so a reference named differently from the public model id fails with ResourceNotFound. Add optional hub_content_name to JumpStartConfig and thread it through from_jumpstart_config; when set, _build_for_jumpstart resolves hub content by the reference's actual name. Verified E2E against a live private hub with an execution role that has zero S3 permissions: an aliased ModelReference now deploys successfully with SageMaker brokering artifact access through the hub content reference. * test(serve): private hub regression coverage for HubAccessConfig and aliased names Unit tests (extends the #5985 file, shared setup hoisted to a module-level _build_jumpstart_builder helper per package convention): - model_reference_arn propagation regression test guarding the #6036 fix (supersedes the subset assertions added there) - CreateModel payload chain test: drives the real unmocked path _build_for_jumpstart -> _prepare_container_def_base and asserts the container definition carries S3DataSource.HubAccessConfig.HubContentArn for hub builds and omits it for public builds -- the assertion that would have caught the v3.15.1-v3.16.0 regression - hub_content_name lookup and config threading tests Integration tests (slow_test, self-provisioning with full teardown): - test_deploy_with_no_s3_execution_role: zero-S3 execution role deploy, asserts HubAccessConfig on the created Model (service-side contract) - test_deploy_with_aliased_hub_content_name: aliased reference deploy Verified red->green at every layer: 4 unit tests and both integ tests fail on v3.16.0 baseline; all pass with the fixes (integ verified live in us-east-1 with a real hub, zero-S3 role, 2 passed in 38s). --------- Co-authored-by: Eli Davidson <elleedee@amazon.com>

zhaoqizqwang · 2026-07-16T20:21:47Z

In _build_for_jumpstart() (model_builder_servers.py), after calling get_init_kwargs(hub_arn=...), the returned model_reference_arn is never copied to self.model_reference_arn. It stays None.

When _prepare_container_def_base() later builds the CreateModel container definition, it reads self.model_reference_arn → None, so no HubAccessConfig is attached to the S3DataSource. Without HubAccessConfig, SageMaker cannot broker artifact access through the private hub and falls back to direct S3 access on jumpstart-cache-prod-* → AccessDenied.

…ight validation Split ecr_policy statements in training, serving, and hyperpod role types so that only ecr:GetAuthorizationToken (account-level) remains under Resource: "*". The repository-level actions (BatchGetImage, GetDownloadUrlForLayer, BatchCheckLayerAvailability) are now scoped to arn:aws:ecr:*:*:repository/*, which excludes them from _get_smoke_test_actions. This prevents SimulatePrincipalPolicy from returning implicitDeny for roles that correctly scope ECR permissions to specific repo ARNs (least privilege), fixing the regression that blocked deploys/training/pipelines for those customers.

_build_for_jumpstart calls get_init_kwargs which resolves model_reference_arn for private hub model references, but never copies it back to self.model_reference_arn. This causes _prepare_container_def_base to omit HubAccessConfig from the CreateModel container definition, making SageMaker fall back to direct S3 access on jumpstart-cache-prod-* and fail with AccessDenied.

Upstream aws#6036 independently fixed the model_reference_arn propagation (Defect A) with the same 6-line fix. Resolution: kept upstream's propagation block as canonical (removed our duplicate at the earlier location), kept our hub_content_name lookup fix (Defect B, not covered upstream), and kept our unit test file as the superset (upstream's 2 tests assert a subset of our TestModelReferenceArnPropagation). Verified post-merge: 17/17 unit tests pass, single propagation block, no conflict markers.

…6039) * fix(serve): support aliased hub content names in private hub deploys CreateHubContentReference accepts a custom HubContentName, but the SDK always looks up hub content by model_id, so a reference named differently from the public model id fails with ResourceNotFound. Add optional hub_content_name to JumpStartConfig and thread it through from_jumpstart_config; when set, _build_for_jumpstart resolves hub content by the reference's actual name. Verified E2E against a live private hub with an execution role that has zero S3 permissions: an aliased ModelReference now deploys successfully with SageMaker brokering artifact access through the hub content reference. * test(serve): private hub regression coverage for HubAccessConfig and aliased names Unit tests (extends the #5985 file, shared setup hoisted to a module-level _build_jumpstart_builder helper per package convention): - model_reference_arn propagation regression test guarding the #6036 fix (supersedes the subset assertions added there) - CreateModel payload chain test: drives the real unmocked path _build_for_jumpstart -> _prepare_container_def_base and asserts the container definition carries S3DataSource.HubAccessConfig.HubContentArn for hub builds and omits it for public builds -- the assertion that would have caught the v3.15.1-v3.16.0 regression - hub_content_name lookup and config threading tests Integration tests (slow_test, self-provisioning with full teardown): - test_deploy_with_no_s3_execution_role: zero-S3 execution role deploy, asserts HubAccessConfig on the created Model (service-side contract) - test_deploy_with_aliased_hub_content_name: aliased reference deploy Verified red->green at every layer: 4 unit tests and both integ tests fail on v3.16.0 baseline; all pass with the fixes (integ verified live in us-east-1 with a real hub, zero-S3 role, 2 passed in 38s). --------- Co-authored-by: Eli Davidson <elleedee@amazon.com>

zhaoqizqwang · 2026-07-16T20:21:47Z

In _build_for_jumpstart() (model_builder_servers.py), after calling get_init_kwargs(hub_arn=...), the returned model_reference_arn is never copied to self.model_reference_arn. It stays None.

When _prepare_container_def_base() later builds the CreateModel container definition, it reads self.model_reference_arn → None, so no HubAccessConfig is attached to the S3DataSource. Without HubAccessConfig, SageMaker cannot broker artifact access through the private hub and falls back to direct S3 access on jumpstart-cache-prod-* → AccessDenied.

…ight validation Split ecr_policy statements in training, serving, and hyperpod role types so that only ecr:GetAuthorizationToken (account-level) remains under Resource: "*". The repository-level actions (BatchGetImage, GetDownloadUrlForLayer, BatchCheckLayerAvailability) are now scoped to arn:aws:ecr:*:*:repository/*, which excludes them from _get_smoke_test_actions. This prevents SimulatePrincipalPolicy from returning implicitDeny for roles that correctly scope ECR permissions to specific repo ARNs (least privilege), fixing the regression that blocked deploys/training/pipelines for those customers.

_build_for_jumpstart calls get_init_kwargs which resolves model_reference_arn for private hub model references, but never copies it back to self.model_reference_arn. This causes _prepare_container_def_base to omit HubAccessConfig from the CreateModel container definition, making SageMaker fall back to direct S3 access on jumpstart-cache-prod-* and fail with AccessDenied.

Upstream aws#6036 independently fixed the model_reference_arn propagation (Defect A) with the same 6-line fix. Resolution: kept upstream's propagation block as canonical (removed our duplicate at the earlier location), kept our hub_content_name lookup fix (Defect B, not covered upstream), and kept our unit test file as the superset (upstream's 2 tests assert a subset of our TestModelReferenceArnPropagation). Verified post-merge: 17/17 unit tests pass, single propagation block, no conflict markers.

…6039) * fix(serve): support aliased hub content names in private hub deploys CreateHubContentReference accepts a custom HubContentName, but the SDK always looks up hub content by model_id, so a reference named differently from the public model id fails with ResourceNotFound. Add optional hub_content_name to JumpStartConfig and thread it through from_jumpstart_config; when set, _build_for_jumpstart resolves hub content by the reference's actual name. Verified E2E against a live private hub with an execution role that has zero S3 permissions: an aliased ModelReference now deploys successfully with SageMaker brokering artifact access through the hub content reference. * test(serve): private hub regression coverage for HubAccessConfig and aliased names Unit tests (extends the #5985 file, shared setup hoisted to a module-level _build_jumpstart_builder helper per package convention): - model_reference_arn propagation regression test guarding the #6036 fix (supersedes the subset assertions added there) - CreateModel payload chain test: drives the real unmocked path _build_for_jumpstart -> _prepare_container_def_base and asserts the container definition carries S3DataSource.HubAccessConfig.HubContentArn for hub builds and omits it for public builds -- the assertion that would have caught the v3.15.1-v3.16.0 regression - hub_content_name lookup and config threading tests Integration tests (slow_test, self-provisioning with full teardown): - test_deploy_with_no_s3_execution_role: zero-S3 execution role deploy, asserts HubAccessConfig on the created Model (service-side contract) - test_deploy_with_aliased_hub_content_name: aliased reference deploy Verified red->green at every layer: 4 unit tests and both integ tests fail on v3.16.0 baseline; all pass with the fixes (integ verified live in us-east-1 with a real hub, zero-S3 role, 2 passed in 38s). --------- Co-authored-by: Eli Davidson <elleedee@amazon.com>

zhaoqizqwang · 2026-07-16T20:21:47Z

In _build_for_jumpstart() (model_builder_servers.py), after calling get_init_kwargs(hub_arn=...), the returned model_reference_arn is never copied to self.model_reference_arn. It stays None.

When _prepare_container_def_base() later builds the CreateModel container definition, it reads self.model_reference_arn → None, so no HubAccessConfig is attached to the S3DataSource. Without HubAccessConfig, SageMaker cannot broker artifact access through the private hub and falls back to direct S3 access on jumpstart-cache-prod-* → AccessDenied.

…ight validation Split ecr_policy statements in training, serving, and hyperpod role types so that only ecr:GetAuthorizationToken (account-level) remains under Resource: "*". The repository-level actions (BatchGetImage, GetDownloadUrlForLayer, BatchCheckLayerAvailability) are now scoped to arn:aws:ecr:*:*:repository/*, which excludes them from _get_smoke_test_actions. This prevents SimulatePrincipalPolicy from returning implicitDeny for roles that correctly scope ECR permissions to specific repo ARNs (least privilege), fixing the regression that blocked deploys/training/pipelines for those customers.

_build_for_jumpstart calls get_init_kwargs which resolves model_reference_arn for private hub model references, but never copies it back to self.model_reference_arn. This causes _prepare_container_def_base to omit HubAccessConfig from the CreateModel container definition, making SageMaker fall back to direct S3 access on jumpstart-cache-prod-* and fail with AccessDenied.

Upstream aws#6036 independently fixed the model_reference_arn propagation (Defect A) with the same 6-line fix. Resolution: kept upstream's propagation block as canonical (removed our duplicate at the earlier location), kept our hub_content_name lookup fix (Defect B, not covered upstream), and kept our unit test file as the superset (upstream's 2 tests assert a subset of our TestModelReferenceArnPropagation). Verified post-merge: 17/17 unit tests pass, single propagation block, no conflict markers.

…6039) * fix(serve): support aliased hub content names in private hub deploys CreateHubContentReference accepts a custom HubContentName, but the SDK always looks up hub content by model_id, so a reference named differently from the public model id fails with ResourceNotFound. Add optional hub_content_name to JumpStartConfig and thread it through from_jumpstart_config; when set, _build_for_jumpstart resolves hub content by the reference's actual name. Verified E2E against a live private hub with an execution role that has zero S3 permissions: an aliased ModelReference now deploys successfully with SageMaker brokering artifact access through the hub content reference. * test(serve): private hub regression coverage for HubAccessConfig and aliased names Unit tests (extends the #5985 file, shared setup hoisted to a module-level _build_jumpstart_builder helper per package convention): - model_reference_arn propagation regression test guarding the #6036 fix (supersedes the subset assertions added there) - CreateModel payload chain test: drives the real unmocked path _build_for_jumpstart -> _prepare_container_def_base and asserts the container definition carries S3DataSource.HubAccessConfig.HubContentArn for hub builds and omits it for public builds -- the assertion that would have caught the v3.15.1-v3.16.0 regression - hub_content_name lookup and config threading tests Integration tests (slow_test, self-provisioning with full teardown): - test_deploy_with_no_s3_execution_role: zero-S3 execution role deploy, asserts HubAccessConfig on the created Model (service-side contract) - test_deploy_with_aliased_hub_content_name: aliased reference deploy Verified red->green at every layer: 4 unit tests and both integ tests fail on v3.16.0 baseline; all pass with the fixes (integ verified live in us-east-1 with a real hub, zero-S3 role, 2 passed in 38s). --------- Co-authored-by: Eli Davidson <elleedee@amazon.com>

zhaoqizqwang · 2026-07-16T20:21:47Z

In _build_for_jumpstart() (model_builder_servers.py), after calling get_init_kwargs(hub_arn=...), the returned model_reference_arn is never copied to self.model_reference_arn. It stays None.

When _prepare_container_def_base() later builds the CreateModel container definition, it reads self.model_reference_arn → None, so no HubAccessConfig is attached to the S3DataSource. Without HubAccessConfig, SageMaker cannot broker artifact access through the private hub and falls back to direct S3 access on jumpstart-cache-prod-* → AccessDenied.

…ight validation Split ecr_policy statements in training, serving, and hyperpod role types so that only ecr:GetAuthorizationToken (account-level) remains under Resource: "*". The repository-level actions (BatchGetImage, GetDownloadUrlForLayer, BatchCheckLayerAvailability) are now scoped to arn:aws:ecr:*:*:repository/*, which excludes them from _get_smoke_test_actions. This prevents SimulatePrincipalPolicy from returning implicitDeny for roles that correctly scope ECR permissions to specific repo ARNs (least privilege), fixing the regression that blocked deploys/training/pipelines for those customers.

_build_for_jumpstart calls get_init_kwargs which resolves model_reference_arn for private hub model references, but never copies it back to self.model_reference_arn. This causes _prepare_container_def_base to omit HubAccessConfig from the CreateModel container definition, making SageMaker fall back to direct S3 access on jumpstart-cache-prod-* and fail with AccessDenied.

Upstream aws#6036 independently fixed the model_reference_arn propagation (Defect A) with the same 6-line fix. Resolution: kept upstream's propagation block as canonical (removed our duplicate at the earlier location), kept our hub_content_name lookup fix (Defect B, not covered upstream), and kept our unit test file as the superset (upstream's 2 tests assert a subset of our TestModelReferenceArnPropagation). Verified post-merge: 17/17 unit tests pass, single propagation block, no conflict markers.

…6039) * fix(serve): support aliased hub content names in private hub deploys CreateHubContentReference accepts a custom HubContentName, but the SDK always looks up hub content by model_id, so a reference named differently from the public model id fails with ResourceNotFound. Add optional hub_content_name to JumpStartConfig and thread it through from_jumpstart_config; when set, _build_for_jumpstart resolves hub content by the reference's actual name. Verified E2E against a live private hub with an execution role that has zero S3 permissions: an aliased ModelReference now deploys successfully with SageMaker brokering artifact access through the hub content reference. * test(serve): private hub regression coverage for HubAccessConfig and aliased names Unit tests (extends the #5985 file, shared setup hoisted to a module-level _build_jumpstart_builder helper per package convention): - model_reference_arn propagation regression test guarding the #6036 fix (supersedes the subset assertions added there) - CreateModel payload chain test: drives the real unmocked path _build_for_jumpstart -> _prepare_container_def_base and asserts the container definition carries S3DataSource.HubAccessConfig.HubContentArn for hub builds and omits it for public builds -- the assertion that would have caught the v3.15.1-v3.16.0 regression - hub_content_name lookup and config threading tests Integration tests (slow_test, self-provisioning with full teardown): - test_deploy_with_no_s3_execution_role: zero-S3 execution role deploy, asserts HubAccessConfig on the created Model (service-side contract) - test_deploy_with_aliased_hub_content_name: aliased reference deploy Verified red->green at every layer: 4 unit tests and both integ tests fail on v3.16.0 baseline; all pass with the fixes (integ verified live in us-east-1 with a real hub, zero-S3 role, 2 passed in 38s). --------- Co-authored-by: Eli Davidson <elleedee@amazon.com>

zhaoqizqwang · 2026-07-16T20:21:47Z

In _build_for_jumpstart() (model_builder_servers.py), after calling get_init_kwargs(hub_arn=...), the returned model_reference_arn is never copied to self.model_reference_arn. It stays None.

When _prepare_container_def_base() later builds the CreateModel container definition, it reads self.model_reference_arn → None, so no HubAccessConfig is attached to the S3DataSource. Without HubAccessConfig, SageMaker cannot broker artifact access through the private hub and falls back to direct S3 access on jumpstart-cache-prod-* → AccessDenied.

…ight validation Split ecr_policy statements in training, serving, and hyperpod role types so that only ecr:GetAuthorizationToken (account-level) remains under Resource: "*". The repository-level actions (BatchGetImage, GetDownloadUrlForLayer, BatchCheckLayerAvailability) are now scoped to arn:aws:ecr:*:*:repository/*, which excludes them from _get_smoke_test_actions. This prevents SimulatePrincipalPolicy from returning implicitDeny for roles that correctly scope ECR permissions to specific repo ARNs (least privilege), fixing the regression that blocked deploys/training/pipelines for those customers.

_build_for_jumpstart calls get_init_kwargs which resolves model_reference_arn for private hub model references, but never copies it back to self.model_reference_arn. This causes _prepare_container_def_base to omit HubAccessConfig from the CreateModel container definition, making SageMaker fall back to direct S3 access on jumpstart-cache-prod-* and fail with AccessDenied.

Upstream aws#6036 independently fixed the model_reference_arn propagation (Defect A) with the same 6-line fix. Resolution: kept upstream's propagation block as canonical (removed our duplicate at the earlier location), kept our hub_content_name lookup fix (Defect B, not covered upstream), and kept our unit test file as the superset (upstream's 2 tests assert a subset of our TestModelReferenceArnPropagation). Verified post-merge: 17/17 unit tests pass, single propagation block, no conflict markers.

…6039) * fix(serve): support aliased hub content names in private hub deploys CreateHubContentReference accepts a custom HubContentName, but the SDK always looks up hub content by model_id, so a reference named differently from the public model id fails with ResourceNotFound. Add optional hub_content_name to JumpStartConfig and thread it through from_jumpstart_config; when set, _build_for_jumpstart resolves hub content by the reference's actual name. Verified E2E against a live private hub with an execution role that has zero S3 permissions: an aliased ModelReference now deploys successfully with SageMaker brokering artifact access through the hub content reference. * test(serve): private hub regression coverage for HubAccessConfig and aliased names Unit tests (extends the #5985 file, shared setup hoisted to a module-level _build_jumpstart_builder helper per package convention): - model_reference_arn propagation regression test guarding the #6036 fix (supersedes the subset assertions added there) - CreateModel payload chain test: drives the real unmocked path _build_for_jumpstart -> _prepare_container_def_base and asserts the container definition carries S3DataSource.HubAccessConfig.HubContentArn for hub builds and omits it for public builds -- the assertion that would have caught the v3.15.1-v3.16.0 regression - hub_content_name lookup and config threading tests Integration tests (slow_test, self-provisioning with full teardown): - test_deploy_with_no_s3_execution_role: zero-S3 execution role deploy, asserts HubAccessConfig on the created Model (service-side contract) - test_deploy_with_aliased_hub_content_name: aliased reference deploy Verified red->green at every layer: 4 unit tests and both integ tests fail on v3.16.0 baseline; all pass with the fixes (integ verified live in us-east-1 with a real hub, zero-S3 role, 2 passed in 38s). --------- Co-authored-by: Eli Davidson <elleedee@amazon.com>

zhaoqizqwang added 4 commits July 14, 2026 13:39

add unit test
7afb616

Merge branch 'master' into fix-private-hub
141b62d

zhaoqizqwang temporarily deployed to auto-approve July 16, 2026 20:55 — with GitHub Actions Inactive

aviruthen approved these changes Jul 16, 2026
View reviewed changes

zhaoqizqwang merged commit 1d91877 into aws:masterJul 16, 2026
12 of 16 checks passed

This was referenced Jul 16, 2026
fix(serve): private hub deploys attach HubAccessConfig and support aliased content names #6035
Closed
fix(serve): support aliased hub content names in private hub deploys #6039
Merged

zhaoqizqwang deleted the fix-private-hub branch July 17, 2026 21:19

github-actionsBot mentioned this pull request Jul 24, 2026
Release 3.17.0 #6099
Merged

zhaoqizqwang added 4 commits July 14, 2026 13:39

add unit test
7afb616

Merge branch 'master' into fix-private-hub
141b62d

zhaoqizqwang temporarily deployed to auto-approve July 16, 2026 20:55 — with GitHub Actions Inactive

aviruthen approved these changes Jul 16, 2026
View reviewed changes

zhaoqizqwang merged commit 1d91877 into aws:masterJul 16, 2026
12 of 16 checks passed

This was referenced Jul 16, 2026
fix(serve): private hub deploys attach HubAccessConfig and support aliased content names #6035
Closed
fix(serve): support aliased hub content names in private hub deploys #6039
Merged

zhaoqizqwang deleted the fix-private-hub branch July 17, 2026 21:19

github-actionsBot mentioned this pull request Jul 24, 2026
Release 3.17.0 #6099
Merged

zhaoqizqwang added 4 commits July 14, 2026 13:39

add unit test
7afb616

Merge branch 'master' into fix-private-hub
141b62d

zhaoqizqwang temporarily deployed to auto-approve July 16, 2026 20:55 — with GitHub Actions Inactive

aviruthen approved these changes Jul 16, 2026
View reviewed changes

zhaoqizqwang merged commit 1d91877 into aws:masterJul 16, 2026
12 of 16 checks passed

This was referenced Jul 16, 2026
fix(serve): private hub deploys attach HubAccessConfig and support aliased content names #6035
Closed
fix(serve): support aliased hub content names in private hub deploys #6039
Merged

zhaoqizqwang deleted the fix-private-hub branch July 17, 2026 21:19

github-actionsBot mentioned this pull request Jul 24, 2026
Release 3.17.0 #6099
Merged

zhaoqizqwang added 4 commits July 14, 2026 13:39

add unit test
7afb616

Merge branch 'master' into fix-private-hub
141b62d

zhaoqizqwang temporarily deployed to auto-approve July 16, 2026 20:55 — with GitHub Actions Inactive

aviruthen approved these changes Jul 16, 2026
View reviewed changes

zhaoqizqwang merged commit 1d91877 into aws:masterJul 16, 2026
12 of 16 checks passed

This was referenced Jul 16, 2026
fix(serve): private hub deploys attach HubAccessConfig and support aliased content names #6035
Closed
fix(serve): support aliased hub content names in private hub deploys #6039
Merged

zhaoqizqwang deleted the fix-private-hub branch July 17, 2026 21:19

github-actionsBot mentioned this pull request Jul 24, 2026
Release 3.17.0 #6099
Merged

zhaoqizqwang added 4 commits July 14, 2026 13:39

add unit test
7afb616

Merge branch 'master' into fix-private-hub
141b62d

zhaoqizqwang temporarily deployed to auto-approve July 16, 2026 20:55 — with GitHub Actions Inactive

aviruthen approved these changes Jul 16, 2026
View reviewed changes

zhaoqizqwang merged commit 1d91877 into aws:masterJul 16, 2026
12 of 16 checks passed

This was referenced Jul 16, 2026
fix(serve): private hub deploys attach HubAccessConfig and support aliased content names #6035
Closed
fix(serve): support aliased hub content names in private hub deploys #6039
Merged

zhaoqizqwang deleted the fix-private-hub branch July 17, 2026 21:19

github-actionsBot mentioned this pull request Jul 24, 2026
Release 3.17.0 #6099
Merged

zhaoqizqwang added 4 commits July 14, 2026 13:39

add unit test
7afb616

Merge branch 'master' into fix-private-hub
141b62d

zhaoqizqwang temporarily deployed to auto-approve July 16, 2026 20:55 — with GitHub Actions Inactive

aviruthen approved these changes Jul 16, 2026
View reviewed changes

zhaoqizqwang merged commit 1d91877 into aws:masterJul 16, 2026
12 of 16 checks passed

This was referenced Jul 16, 2026
fix(serve): private hub deploys attach HubAccessConfig and support aliased content names #6035
Closed
fix(serve): support aliased hub content names in private hub deploys #6039
Merged

zhaoqizqwang deleted the fix-private-hub branch July 17, 2026 21:19

github-actionsBot mentioned this pull request Jul 24, 2026
Release 3.17.0 #6099
Merged

zhaoqizqwang added 4 commits July 14, 2026 13:39

add unit test
7afb616

Merge branch 'master' into fix-private-hub
141b62d

zhaoqizqwang temporarily deployed to auto-approve July 16, 2026 20:55 — with GitHub Actions Inactive

aviruthen approved these changes Jul 16, 2026
View reviewed changes

zhaoqizqwang merged commit 1d91877 into aws:masterJul 16, 2026
12 of 16 checks passed

This was referenced Jul 16, 2026
fix(serve): private hub deploys attach HubAccessConfig and support aliased content names #6035
Closed
fix(serve): support aliased hub content names in private hub deploys #6039
Merged

zhaoqizqwang deleted the fix-private-hub branch July 17, 2026 21:19

github-actionsBot mentioned this pull request Jul 24, 2026
Release 3.17.0 #6099
Merged

zhaoqizqwang added 4 commits July 14, 2026 13:39

add unit test
7afb616

Merge branch 'master' into fix-private-hub
141b62d

zhaoqizqwang temporarily deployed to auto-approve July 16, 2026 20:55 — with GitHub Actions Inactive

aviruthen approved these changes Jul 16, 2026
View reviewed changes

zhaoqizqwang merged commit 1d91877 into aws:masterJul 16, 2026
12 of 16 checks passed

This was referenced Jul 16, 2026
fix(serve): private hub deploys attach HubAccessConfig and support aliased content names #6035
Closed
fix(serve): support aliased hub content names in private hub deploys #6039
Merged

zhaoqizqwang deleted the fix-private-hub branch July 17, 2026 21:19

github-actionsBot mentioned this pull request Jul 24, 2026
Release 3.17.0 #6099
Merged

Uh oh!

Conversation

zhaoqizqwang commented Jul 16, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Uh oh!

Conversation

zhaoqizqwang commented Jul 16, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Uh oh!

Conversation

zhaoqizqwang commented Jul 16, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Uh oh!

Conversation

zhaoqizqwang commented Jul 16, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Uh oh!

Conversation

zhaoqizqwang commented Jul 16, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Uh oh!

Conversation

zhaoqizqwang commented Jul 16, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Uh oh!

Conversation