dh-cli 0.7.0__tar.gz → 0.7.1__tar.gz

{dh_cli-0.7.0 → dh_cli-0.7.1}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: dh-cli
-Version: 0.7.0
+Version: 0.7.1
 Summary: Dayhoff Labs developer CLI
 Author-email: Dayhoff Labs <dev@dayhofflabs.com>
 License: # PolyForm Noncommercial License 1.0.0

{dh_cli-0.7.0 → dh_cli-0.7.1}/pyproject.toml

@@ -4,7 +4,7 @@ build-backend = "hatchling.build"
 
 [project]
 name = "dh-cli"
-version = "0.7.0"
+version = "0.7.1"
 description = "Dayhoff Labs developer CLI"
 requires-python = ">=3.11"
 readme = "README.md"

dh_cli-0.7.1/src/dh_cli/_identity.py

@@ -0,0 +1,82 @@
+"""Identity resolution for `dh` commands that read per-developer secrets.
+
+The `github_commands` and (future) `bedrock` commands both key per-user
+Secrets Manager entries on the caller's Dayhoff handle. This module
+resolves that handle from the current SSO session in a way that matches
+the server-side resource policy (which keys on
+`aws:PrincipalTag/Email`).
+
+Design note — why not session tags directly?
+
+    AWS Secrets Manager resource policies evaluate
+    `aws:PrincipalTag/Email` automatically because IAM Identity Center
+    attaches an `Email` principal tag to DeveloperAccess sessions. But
+    there is no SDK API that lets a session read its own principal
+    tags back — session tags are visible *only* to IAM condition
+    evaluation, not to callers. The closest observable we have is the
+    assumed-role ARN's RoleSessionName, which Identity Center sets to
+    the user's email by default.
+
+    So the resolution below extracts the RoleSessionName and strips the
+    `@<domain>` suffix if present. This matches what the policy's
+    `aws:PrincipalTag/Email` condition will also evaluate to at
+    GetSecretValue time — i.e. "which secret can I read?" and "what
+    handle am I?" are answered by the same identity fact by
+    construction.
+
+CANARY (resolve pre-code-freeze, plan §"Pre-implementation canaries"
+Canary 1): confirm the RoleSessionName on DeveloperAccess is
+`<handle>@dayhoff.com` and not `<handle>@dayhofflabs.com`. The
+DEFAULT_DOMAIN constant below is the single place to flip that.
+"""
+from __future__ import annotations
+
+import re
+
+DEFAULT_DOMAIN = "dayhoff.com"
+
+_SSO_ASSUMED_ROLE_RE = re.compile(
+    r"^arn:aws:sts::\d+:assumed-role/AWSReservedSSO_[^/]+/(?P<session>.+)$"
+)
+
+
+class HandleResolutionError(RuntimeError):
+    """Raised when the current session's handle can't be determined.
+
+    The caller is expected to turn this into a user-facing error
+    pointing at `awslogin dev-devaccess`.
+    """
+
+
+def resolve_handle_from_session(session, *, domain: str = DEFAULT_DOMAIN) -> str:
+    """Return the dev handle matching the SSO session's Email principal tag.
+
+    Args:
+        session: a boto3 Session configured with the caller's SSO
+            credentials. The function calls `sts:GetCallerIdentity` on
+            it; if that call would fall through to the engine instance
+            role instead of the dev's SSO creds, the caller must have
+            already detected and errored on that before getting here
+            (see `github_commands._sso_session`).
+        domain: email domain to strip from the session name. Defaults to
+            `dayhoff.com` to match `cursor_bedrock_role.tf`'s tag.
+
+    Returns:
+        The handle (e.g. `"dma"`).
+
+    Raises:
+        HandleResolutionError: the caller's ARN doesn't look like an
+            Identity Center DeveloperAccess session.
+    """
+    arn = session.client("sts").get_caller_identity()["Arn"]
+    match = _SSO_ASSUMED_ROLE_RE.match(arn)
+    if not match:
+        raise HandleResolutionError(
+            f"Caller ARN does not look like an AWS SSO session: {arn}. "
+            f"Run `awslogin dev-devaccess` (or pass --handle explicitly)."
+        )
+    session_name = match.group("session")
+    suffix = f"@{domain}"
+    if session_name.endswith(suffix):
+        return session_name[: -len(suffix)]
+    return session_name