@aws-cdk/aws-lambda-python-alpha: Docker build does not work with podman.

[urkle]

Describe the bug

When the aws-cdk.lambda-python-alpha package uses a container to package up a layer it passes in parameters that are not needed with podman (due to it running as the user).

Thus the CLI that is generated when prepping a layer looks like this.

docker run --rm \
  -u "501:20" \
  -v "/Users/urkle/Projects/Netfor/CDK/netfor-cdk/smp_lambdas/src/layer_google:/asset-input:delegated" \
  -v "/Users/urkle/Projects/Netfor/CDK/netfor-cdk/cdk.out/asset.2b2e755e90bc7b0c887c1688b8b6d93ed65c286ed49bca0f6425b999735a9b09:/asset-output:delegated" \
  -w "/asset-input" cdk-de18f6cee13cbafcdf0bad83fb66063b89b266a182dd361054851531a4bed9a0 \
  bash -c "rsync -rLv /asset-input/ /asset-output/python && cd /asset-output/python && python -m pip install -r requirements.txt -t /asset-output/python"

However, the user mapping -u 501:20 causes issues with podman and causes permission denied errors for the script.

Removing that mapping allows the script to work.

Further when running in that mode the output folder ( asset.2b2e755e90bc7b0c887c1688b8b6d93ed65c286ed49bca0f6425b999735a9b09 ) does not need to be world writable (777).

Related #31319

Regression Issue

• Select this option if this issue appears to be a regression.

Last Known Working CDK Version

No response

Expected Behavior

The CDK process works. (and podman is becoming more common especially with the unfriendly licenses of Docker Desktop)

Current Behavior

Error from the rsync command when running with -u "501:20"

ERROR: Could not open requirements file: [Errno 13] Permission denied: 'requirements.txt'

Reproduction Steps

PythonLayerVersion(
self,
'CustomLayer',
entry=scriptPath('src/layer'),
compatible_runtimes=[_lambda.Runtime.PYTHON_3_11],
)

Possible Solution

Allow for specifying/detecting podman vs docker so differing behaviors can be applied

Additional Information/Context

No response

CDK CLI Version

2.166.0

Framework Version

No response

Node.js Version

18.16.1

OS

macOS 12.7.6

Language

Python

Language Version

3.11

Other information

No response

[urkle]

From what I can tell this seems to be an issue with the core aws-cdk-lib code that is forcing a user parameter always. (

aws-cdk/packages/aws-cdk-lib/core/lib/private/asset-staging.ts

Lines 29 to 42 in 6303b72

	protected determineUser() {
	let user: string;
	if (this.options.user) {
	user = this.options.user;
	} else {
	// Default to current user
	const userInfo = os.userInfo();
	user =
	userInfo.uid !== -1 // uid is -1 on Windows
	? `${userInfo.uid}:${userInfo.gid}`
	: '1000:1000';
	}
	return user;
	}

)

I hacked it up by creating a custom "docker" script in the path so cdk will use that instead. And the only thing the script does it remove the -u X parameter.

[pahud]

I am not familiar with podman but I've been using finch in my mac os X m1 and it works pretty great.

Question:

1. how did you run it with podman, did you export CDK_DOCKER='podman' ?
2. have you ever successfully run it with podman with that?
3. have you tried finch? Does it work for you?

[urkle]

@pahud Podman is an alternative to Docker that runs in user space vs as root. (more secure)

So, finch does not come into play at all.

the issue centers around aws-cdk-lib's assumption that it is using a ROOT docker and needs to force the container to run as the local user to map file permissions correctly. This is not the case with Podman.

Podman

1. uses user mapping internally so that the container "0" == the host "my user id".
2. When aws-cdk-lib passes -u 501:20 (or whatever your local user/group are) it actually runs as a different virtual user in the container that now no longer has access to the mapped volume to write to it.
3. Either omitting -u 501:20 (thus using the container default of root/0) OR specifying 0:0 allows the build to work.
   • I found this one out today I can specify bundling=lambda_python.BundlingOptions(user='0:0') as a parameter to my lambda_python.PythonLayerVersionconstructor and it works.

Thus having some detection of podman and adjusting some of the defaults to make it behave more friendly would make CDK even better. Another option would be to allow some kind of user-level configuration adjustments to default the behavior differently without having to modify the stack setup with local-environment related adjustments.

I cannot (and will not) use Docker desktop on my mac, as the licensing prohibits me from using it without paying for a license for commercial use (see license info).