In Dockerfiles and Docker images, CMD
and ENTRYPOINT
define the default behavior of a container. Each have an important role to play:
CMD
specifies the arguments that are passed to the container at runtime. However, it can be overridden by user inputENTRYPOINT
sets the executable to run inside the container. UnlikeCMD
,ENTRYPOINT
cannot be overwritten and will always execute the specified command regardless of additional inputs
Note: It is only mandatory that either CMD
or ENTRYPOINT
is set as this defines the container's default behaviour.
Prisma Cloud leverages the ENTRYPOINT
to monitor and secure containerised applications by injecting security controls at the container startup phase. By enforcing security checks and controls within the ENTRYPOINT
, Prisma Cloud ensures that critical security policies are applied before the application becomes operational. This approach enhances security by detecting vulnerabilities, misconfigurations, and potential threats early in the container lifecycle.
Given that a Docker image is valid so long as it contains either a CMD
or ENTRYPOINT
, images that contain only a CMD
cannot be secured by Prisma Cloud. This can be resolved using one of the following methods:
-
Update their Dockerfile to include an
ENTRYPOINT
-
Specify the
ENTRYPOINT
(and optionally theCMD
) in their Fargate Container DefinitionsNote: While the
ENTRYPOINT
cannot be modified in a traditional Docker environment, it can be modified in an AWS Container Definition
The 2nd option is often the preferred as it negates the need for devs to update all of their Dockerfiles and ensure their 3rd party images have an ENTRYPOINT
. Additionally, scripts like ENTRYPOINT Creator can be added to CI/CD pipelines to make the the entire process automated and transparent.
ENTRYPOINT Creator automates the extraction of the CMD
command from Docker images and generates Task Definitions based on the task_definition_template.json
template.
The created Definitions are:
-
task_definition_with_entrypoint.json
: Converts theCMD
command into anENTRYPOINT
command in the Task Definition -
task_definition_with_entrypoint_and_cmd.json
: Converts and splits theCMD
command to populateENTRYPOINT
andCMD
See the Script Execution section for a detailed view of the script's execution flow.
├── README.md (this file)
├── run.sh (the script)
├── src
│ ├── fargate
│ │ └── task_definition_template.json (AWS Fargate Task Definition template used by the script)
│ └── redis
│ ├── Dockerfile (used to create a customised redis image)
│ └── redis.conf (used to create a customised redis image)
├── task_definition_with_entrypoint.json (file generated by the script)
└── task_definition_with_entrypoint_and_cmd.json (file generated by the script)
- Create the Docker image
cd src/redis
docker build -t example-redis-image .
- Run the script:
cd -
./run.sh example-redis-image
ENTRYPOINT Creator starts by running the docker inspect
command. If it sees that an ENTRYPOINT
has been defined in the image, it'll log the following messages and termiante the script:
Checking for ENTRYPOINT
ENTRYPOINT search result for redis: FOUND - ["docker-entrypoint.sh"]
Exiting script
If it does not find one, it'll extract the CMD
command from the output and provides the following log message:
Extracted CMD: ["redis-server","/usr/local/etc/redis/redis.conf"]
Next, it starts creating the new task_definition_with_entrypoint.json
Task Definition. First it reads the Task Definition template file (task_definition_template.json
). Then it removes the empty CMD
array. Finally, it updates the empty ENTRYPOINT
array and outputs the contents to task_definition_with_entrypoint.json
.
The following messages are logged during this process:
Creating new ENTRYPOINT Task Definition file: /tmp/AutoEntrypoint/task_definition_with_entrypoint.json
Reading Task Definition template file: /tmp/AutoEntrypoint/src/fargate/task_definition_template.json
Removed: Empty CMD array from template
Set ENTRYPOINT to: ["redis-server","/usr/local/etc/redis/redis.conf"]
Output ENTRYPOINT Task Definition to a new file: /tmp/AutoEntrypoint/task_definition_with_entrypoint.json
The script then follows a similar flow to create the task_definition_with_entrypoint_and_cmd.json
Task Definition. The following messages are logged during this process:
Creating new ENTRYPOINT & CMD Task Definition file: /tmp/AutoEntrypoint/task_definition_with_entrypoint.json
Reading Task Definition template file: /tmp/AutoEntrypoint/src/fargate/task_definition_template.json
Splitting command into ENTRYPOINT and CMD: ["redis-server","/usr/local/etc/redis/redis.conf"]
Extracted ENTRYPOINT: redis-server
Extracted CMD: ["/usr/local/etc/redis/redis.conf"]
Update template and output ENTRYPOINT & CMD Task Definition to a new file: /tmp/AutoEntrypoint/task_definition_with_entrypoint.json
A summary of the process is provided at the end of the execution:
######################################################################################################################################################
EXECUTION SUCCESSFUL
######################################################################################################################################################
Successfully Extracted CMD command ["redis-server","/usr/local/etc/redis/redis.conf"] and created two new Task Definition files:
ENTRYPOINT Task Definition: /tmp/AutoEntrypoint/task_definition_with_entrypoint.json
ENTRYPOINT & CMD Task Definition: /tmp/AutoEntrypoint/task_definition_with_entrypoint_and_cmd.json
######################################################################################################################################################
The new Task Definition files simply contain the contents of the task_definition_template.json
with the modifications made to the CMD
and ENTRYPOINT
arrays as necessary.
In this example, task_definition_with_entrypoint.json
looks like this:
"entryPoint": [
"redis-server",
"/usr/local/etc/redis/redis.conf"
],
And, task_definition_with_entrypoint_and_cmd.json
looks like this:
"entryPoint": [
"redis-server"
],
"command": [
"/usr/local/etc/redis/redis.conf"
],