SageMakerClient ignores the passed boto3 session for the "sagemaker" client since 2.13.0 — all resource API calls sign with default-chain credentials
Maintainer antworten meist innerhalb von 2 Tagen
Dieses Issue hat noch niemand übernommen.
Bewertung
- Schwierigkeit
- 4/5
- Geschätzter Aufwand
- 3-5 Tage
- Anfängerfreundlichkeit
- 58/100
- Issue-Typ
- Bug
- Klarheit
- Klar beschrieben
- Aktivitätsstatus
- Ruhig
- Tech-Stack
- aws, python
- Bereich
- backend-api-design, cloud, security
Rechercherichtung
Beginnen Sie in sagemaker-core/src/sagemaker/core/utils/utils.py bei SageMakerClient.init, und verfolgen Sie anschließend Base.get_sagemaker_client(session=...) und get_client("sagemaker"). Führen Sie die bereitgestellte Reproduktion zum Vergleich der Anmeldeinformationen aus, ohne AWS-Ressourcen zu erstellen. Das Ziel ist erreicht, wenn der sagemaker-Client mit den Anmeldeinformationen der ausdrücklich übergebenen Session signiert und dabei das benutzerdefinierte Verhalten des Service-Modells beibehält.
Vom Indexierungsmodell aus dem Issue-Text verfasst.
Beschreibung
TL;DR — Since sagemaker-core 2.13.0, SageMakerClient ignores the session= the caller passed and builds its main sagemaker client from a fresh default-chain session. Every V3 resource API call (FeatureGroup.create, Model.create, describe/delete/list, …) is silently signed with ambient credentials instead of the caller's.
Besides breaking explicit-session workflows, this is a quiet identity mix-up with a security edge: code written to run under a scoped or assumed role can instead execute under a less-privileged (or worse a more-privileged) ambient identity, with no error or warning. Last good version: 2.12.0. Workaround: pin sagemaker-core>=2.12,<2.13.
PySDK Version
- PySDK V2 (2.x)
- PySDK V3 (3.x)
Describe the bug
SageMakerClient.__init__ (sagemaker-core/src/sagemaker/core/utils/utils.py) contains a block introduced by #5919 (merged 2026-06-03, released as sagemaker-core 2.13.0) that loads a custom service model for pre-GA Job APIs through a brand-new botocore session:
# TODO: Remove post-launch. This loads a custom botocore service model
# (from the 'sample/' directory) that includes pre-GA Job APIs ...
bc_session = bc_session_mod.get_session()
...
custom_session = Session(botocore_session=bc_session, region_name=env_region)
self.sagemaker_client = custom_session.client("sagemaker", ...) # <-- passed `session` ignored
custom_session resolves credentials from the default provider chain (env vars / AWS_PROFILE / IMDS), discarding the passed session's credentials. The other clients built in the same constructor (sagemaker-runtime, sagemaker-featurestore-runtime, sagemaker-metrics) still correctly use the passed session.
Since every resource class routes through Base.get_sagemaker_client(session=...) → SageMakerClient(...).get_client("sagemaker"), all V3 resource API calls are affected.
To reproduce
Minimal proof, no AWS resources created — the returned client does not hold the passed session's credentials:
import boto3
from sagemaker.core.utils.utils import SageMakerClient
# Any session whose credentials differ from the default provider chain,
# e.g. an assumed role:
sts = boto3.client("sts")
creds = sts.assume_role(
RoleArn="arn:aws:iam::<ACCOUNT_ID>:role/<SomeRole>",
RoleSessionName="repro",
)["Credentials"]
session = boto3.Session(
aws_access_key_id=creds["AccessKeyId"],
aws_secret_access_key=creds["SecretAccessKey"],
aws_session_token=creds["SessionToken"],
region_name="us-west-2",
)
client = SageMakerClient(session=session, region_name="us-west-2").get_client("sagemaker")
client_key = client._request_signer._credentials.get_frozen_credentials().access_key
print("passed session key:", session.get_credentials().access_key)
print("client signs with :", client_key)
assert client_key == session.get_credentials().access_key, "client ignored the passed session"
The assert passes on 2.12.0 and fails on 2.13.0–2.15.0.
The same code with sagemaker-core 2.12.0 (identical credentials, identical account) succeeds.
Expected behavior
When a session is passed to SageMakerClient (directly or via any resource method's session= parameter), every client it constructs — including sagemaker — signs requests with that session's credentials. If the custom service-model loader is still needed, attach it to the passed session's botocore session rather than creating a new default-chain session.
System information
- SageMaker Python SDK version: sagemaker 3.13.1 / sagemaker-core 2.13.1 (broken); still present in sagemaker-core 2.15.0; last good 2.12.0
- Framework name / algorithm: n/a (Feature Store / core resource classes)
- Python version: 3.13
- CPU or GPU: CPU
- Custom Docker image (Y/N): N (bare venv on macOS)
Additional context
- The bug is easy to miss on EC2/ECS/Batch/SageMaker jobs because the default chain resolves to the attached role — the wrong session happens to be the right identity. It bites exactly when an explicit session matters: assumed roles, cross-account work, multi-profile laptops.
- Two smaller quirks in the same block, worth fixing together:
SageMakerClientis a singleton (SingletonMeta), so even the correctly-handled clients only honor whichever session arrives first in the process.logger.info(f"Runs on sagemaker {env_stage}, region:{env_region}")logs on every construction and reads like leftover debug output.
- Introduced by #5919
- Vorherrschende Sprache
- Python
- Sterne
- 2.3k
- Forks
- 1.3k
- Ø Merge
- 3 T. 10 Std.
- Gemergte PRs (30 T.)
- 82
Entwicklungsumgebung
- Kein Dockerfile und keine Docker-Compose-Datei
- Keine Pull-Request-Vorlage
- Beitragsleitfaden lesen
Erste Schritte
- Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
- Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
- Forken Sie das Repository und arbeiten Sie in einem Branch.
- Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.
Mehr aus aws/sagemaker-python-sdk
-
Cannot use spark_event_logs_s3_uri in PySparkProcessor jobEvtl. vergeben @rsareddy0329 hat das vor 7 Tagen übernommen. Offen
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 78/100
aws/sagemaker-python-sdk#6253 ·
Maintainer antworten meist innerhalb von 2 Tagen
-
[Bug] V3 Hyperparameter Tuning Pipeline page labelled "Download Data" in navigation due to missing title cellEvtl. vergeben @admivsn hat das vor 36 Tagen übernommen. Offen
Schwierigkeit 1/5 Unter einer Stunde Anfängerfreundlichkeit 93/100
aws/sagemaker-python-sdk#6232 ·
Maintainer antworten meist innerhalb von 2 Tagen
-
[Bug] ModelTrainer with no input channels emits InputDataConfig: [], which CreatePipeline rejects (min=1) — v2 omitted the keyEvtl. vergeben @sagemaker-bot hat das vor 7 Tagen übernommen. Offen
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 76/100
aws/sagemaker-python-sdk#6156 · 2 Kommentare ·
Maintainer antworten meist innerhalb von 2 Tagen
-
sagemaker-train should depend on mlflow-skinny, following sagemaker-mlflow 0.5.0Evtl. vergeben @mohamedzeidan2021 hat das vor 8 Tagen übernommen. Offen
Schwierigkeit 2/5 Ein halber Tag Anfängerfreundlichkeit 72/100
aws/sagemaker-python-sdk#6152 ·
Maintainer antworten meist innerhalb von 2 Tagen
-
ModelTrainer generates sm_train.sh with CRLF line endings on Windows causing training job failureEvtl. vergeben @MohammedAlkindi hat das vor 27 Tagen übernommen. Offen
Schwierigkeit 1/5 Unter einer Stunde Anfängerfreundlichkeit 88/100
aws/sagemaker-python-sdk#5904 · 1 Reaktion ·
Maintainer antworten meist innerhalb von 2 Tagen
Alle Issues in aws/sagemaker-python-sdk
Ähnliche Issues
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 68/100
-
Task
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 65/100
Maintainer antworten meist innerhalb von 1 Tag
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 86/100
war-and-code/dircue#200 ·
Maintainer antworten meist innerhalb von 1 Tag
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 87/100
Maintainer antworten meist innerhalb von 1 Tag
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 84/100
Maintainer antworten meist innerhalb von 1 Tag