@kensio/yulin 1.21.19 → 1.21.20

package/dist/service/lambda/function/environment/sim-lambda-execution-credentials.d.ts

@@ -16,3 +16,28 @@ export declare const simLambdaExecutionCredentials: readonly (readonly [
     string,
     string
 ])[];
+/**
+ * The host environment variable names that point an AWS SDK at credentials
+ * outside the invocation.
+ *
+ * A function declaring no variables of its own runs with the host process
+ * environment underneath the AWS-provided ones, which is where an in-process
+ * handler reads its configuration from. These names are not that
+ * configuration. They are how a developer's shell and a CI runner select the
+ * AWS access they hold themselves, and real Lambda sets none of them.
+ *
+ * `AWS_PROFILE` is the one that stops an invocation outright. The Node.js
+ * credential provider chain skips its environment-variable provider whenever
+ * that name is set, reporting "AWS_PROFILE is set, skipping fromEnv
+ * provider.", and the placeholder credentials above go unread. Resolution
+ * leaves the simulation for a shared configuration file or an SSO portal, and
+ * the client throws while resolving, before the request it was building
+ * reaches a simulated service. The rest each name a credential source of their
+ * own and are masked for the same reason.
+ */
+export declare const hostAwsCredentialVariableNames: ReadonlySet<string>;
+/**
+ * The host process variables an invocation keeps, with the ones naming a
+ * credential source of the host's own left out.
+ */
+export declare function withoutHostAwsCredentialVariables(variables: Record<string, string>): Record<string, string>;

package/dist/service/lambda/function/environment/sim-lambda-execution-credentials.js

@@ -17,3 +17,48 @@ export const simLambdaExecutionCredentials = [
     ["AWS_SECRET_ACCESS_KEY", "yulinSimulatedSecretAccessKeyValue000000"],
     ["AWS_SESSION_TOKEN", "yulin-simulated-session-token"],
 ];
+/**
+ * The host environment variable names that point an AWS SDK at credentials
+ * outside the invocation.
+ *
+ * A function declaring no variables of its own runs with the host process
+ * environment underneath the AWS-provided ones, which is where an in-process
+ * handler reads its configuration from. These names are not that
+ * configuration. They are how a developer's shell and a CI runner select the
+ * AWS access they hold themselves, and real Lambda sets none of them.
+ *
+ * `AWS_PROFILE` is the one that stops an invocation outright. The Node.js
+ * credential provider chain skips its environment-variable provider whenever
+ * that name is set, reporting "AWS_PROFILE is set, skipping fromEnv
+ * provider.", and the placeholder credentials above go unread. Resolution
+ * leaves the simulation for a shared configuration file or an SSO portal, and
+ * the client throws while resolving, before the request it was building
+ * reaches a simulated service. The rest each name a credential source of their
+ * own and are masked for the same reason.
+ */
+export const hostAwsCredentialVariableNames = new Set([
+    "AWS_CONTAINER_AUTHORIZATION_TOKEN",
+    "AWS_CONTAINER_AUTHORIZATION_TOKEN_FILE",
+    "AWS_CONTAINER_CREDENTIALS_FULL_URI",
+    "AWS_CONTAINER_CREDENTIALS_RELATIVE_URI",
+    "AWS_CONFIG_FILE",
+    "AWS_DEFAULT_PROFILE",
+    "AWS_PROFILE",
+    "AWS_ROLE_ARN",
+    "AWS_ROLE_SESSION_NAME",
+    "AWS_SHARED_CREDENTIALS_FILE",
+    "AWS_WEB_IDENTITY_TOKEN_FILE",
+]);
+/**
+ * The host process variables an invocation keeps, with the ones naming a
+ * credential source of the host's own left out.
+ */
+export function withoutHostAwsCredentialVariables(variables) {
+    const kept = [];
+    for (const [name, value] of Object.entries(variables)) {
+        if (!hostAwsCredentialVariableNames.has(name)) {
+            kept.push([name, value]);
+        }
+    }
+    return Object.fromEntries(kept);
+}

package/dist/service/lambda/function/environment/sim-lambda-host-backed-variables.d.ts

@@ -6,6 +6,11 @@
  * merged once, so a variable the test process sets between two invocations
  * reaches the second of them.
  *
+ * The host's own AWS credential variables are left out. An invocation is
+ * attributed to the function's execution Role, and a name pointing an SDK at
+ * the credentials of whoever started the test process would make the
+ * invocation depend on them. See `hostAwsCredentialVariableNames`.
+ *
  * What the handler itself wrote is kept and laid over both, which is the warm
  * execution environment semantics a function declaring variables gets from
  * reusing one object. A name the handler wrote and the host also sets is the

package/dist/service/lambda/function/environment/sim-lambda-host-backed-variables.js

@@ -1,4 +1,5 @@
 import { simProcessEnvironment } from "../../../../util/process/sim-process-environment.js";
+import { withoutHostAwsCredentialVariables } from "./sim-lambda-execution-credentials.js";
 /**
  * The environment of a function that declares no variables of its own.
  *
@@ -7,6 +8,11 @@ import { simProcessEnvironment } from "../../../../util/process/sim-process-envi
  * merged once, so a variable the test process sets between two invocations
  * reaches the second of them.
  *
+ * The host's own AWS credential variables are left out. An invocation is
+ * attributed to the function's execution Role, and a name pointing an SDK at
+ * the credentials of whoever started the test process would make the
+ * invocation depend on them. See `hostAwsCredentialVariableNames`.
+ *
  * What the handler itself wrote is kept and laid over both, which is the warm
  * execution environment semantics a function declaring variables gets from
  * reusing one object. A name the handler wrote and the host also sets is the
@@ -19,7 +25,7 @@ export class SimLambdaHostBackedVariables {
      */
     async runWith(functionVariables, run) {
         const merged = {
-            ...simProcessEnvironment.definedHostVariables(),
+            ...withoutHostAwsCredentialVariables(simProcessEnvironment.definedHostVariables()),
             ...functionVariables,
             ...Object.fromEntries(this.written),
         };

package/docs/services/lambda/README.md

@@ -3158,6 +3158,16 @@ that is where such a handler's configuration comes from when nothing declares it
 variables on the function keeps the test explicit about where they came from. Zip-packaged code in
 the vm runtime gets the function's own variables either way, and never the test process's.
 
+One group of host variables is masked whatever the function declares. `AWS_PROFILE`,
+`AWS_DEFAULT_PROFILE`, `AWS_CONFIG_FILE`, `AWS_SHARED_CREDENTIALS_FILE`,
+`AWS_WEB_IDENTITY_TOKEN_FILE`, `AWS_ROLE_ARN`, `AWS_ROLE_SESSION_NAME` and the
+`AWS_CONTAINER_CREDENTIALS_*` and `AWS_CONTAINER_AUTHORIZATION_*` names go unset for the length of
+an invocation. Each of them points an AWS SDK at credentials held by whoever started the test
+process, and a client built in a handler follows one straight out of the simulation. `AWS_PROFILE`
+does that even with the placeholder credentials above in place, because the Node.js credential
+provider chain skips its environment-variable provider whenever a profile is named. Masking them
+keeps a test independent of the machine running it, and real Lambda sets none of them anyway.
+
 This is also how a function reaches something outside the simulation, such as a Redis or a
 Postgres. See [non-AWS dependencies](https://yulinsim.dev/non-aws-dependencies/).
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@kensio/yulin",
-  "version": "1.21.19",
+  "version": "1.21.20",
   "description": "AWS system behaviour simulation for isolated unit testing",
   "repository": "https://github.com/KensioSoftware/yulin",
   "homepage": "https://yulinsim.dev/",