Container and Serverless Security

What it is

Containers and serverless functions move more responsibility to AWS but add their own risks: vulnerable images, over broad roles, secrets in environment variables and open network paths. The shared responsibility line shifts, yet identity, code and configuration remain yours.

For the exam, focus on three questions: how the image or code is verified, which identity the workload runs as, and what it can reach on the network.

How it works

Container images and ECR

Amazon Elastic Container Registry (ECR) stores images. Secure the supply chain with these controls.

• Image scanning. Basic scanning checks images for known vulnerabilities, and enhanced scanning uses Amazon Inspector for continuous scanning of OS and programming language packages.
• Immutable tags. Prevent a tag from being overwritten with different content.
• Repository policies and IAM. Limit who can push and pull, including cross account pulls.
• Encryption. Repositories are encrypted at rest, with an option to use a customer managed KMS key.
• Signing. Sign images and verify the signature before deploy, so only trusted builds run.
• Lifecycle rules. Remove old images that carry known vulnerabilities.

Use minimal base images, run as a non root user, and use a read only root file system where possible.

Amazon ECS

ECS tasks use two different roles, and the exam often tests the difference.

Give each task definition its own task role. Inject secrets from Secrets Manager or Parameter Store using the secrets field of the container definition rather than plain environment variables. With the awsvpc network mode, each task gets its own network interface and security group, which allows task level network control.

Fargate runs each task in its own isolated environment with no access to the underlying host, so there is no node patching or host access to manage.

Amazon EKS

Without pod level identity, all pods on a node share the node role and any compromised pod gets every permission of that role. IRSA and Pod Identity fix that by giving each service account its own role.

AWS Lambda

• Execution role. One role per function with only the actions it needs. The role is the function's identity.
• Resource based policy. Controls who can invoke the function, such as a service or another account, which is separate from the execution role.
• Environment variables. They are encrypted at rest, and for sensitive values use a customer managed KMS key and encryption helpers, or better, fetch secrets at runtime from Secrets Manager.
• VPC access. Attach a function to a VPC only when it must reach private resources, then control it with security groups and, for internet access, a NAT gateway.
• Code signing. With a code signing configuration based on AWS Signer, Lambda accepts only packages signed by trusted publishers.
• Dependencies. Inspector can scan function code and its libraries for vulnerabilities.
• Concurrency. Reserved concurrency can limit the blast radius, and setting it to zero stops a compromised function from running.

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Action": ["dynamodb:GetItem", "dynamodb:PutItem"],
    "Resource": "arn:aws:dynamodb:us-east-1:111122223333:table/Orders"
  }]
}

This policy gives a function access to two actions on one table, which is the shape of a least privilege execution role.

Secrets for workloads

Do not bake secrets into images or code. Use Secrets Manager or Parameter Store, grant the task or function role read access to only its secrets, and use VPC endpoints when workloads have no internet path.

Network isolation

Place workloads in private subnets, give them security groups that allow only required flows, and use VPC endpoints for AWS APIs. For EKS and ECS, separate sensitive workloads into different clusters or accounts when the trust boundary calls for it.

Generative AI workloads on Amazon Bedrock

A generative AI application adds new risks on top of the usual compute controls: untrusted text steers the model, and the model may leak data or trigger actions. The Open Worldwide Application Security Project (OWASP) publishes a Top 10 list of risks for large language model (LLM) applications. Skill 3.2.7 asks you to put guardrails against those risks in place.

Amazon Bedrock Guardrails check both the user input and the model response against rules you define.

• Content filters block harmful categories and also include a prompt attack filter for jailbreak and prompt injection attempts.
• Denied topics keep the application off subjects you describe.
• Sensitive information filters detect personally identifiable information (PII) and either block or mask it.
• Word filters block specific words or phrases.

A guardrail is created once, versioned, and then attached to model calls. The ApplyGuardrail API lets you apply the same guardrail to text from any model, even one outside Bedrock.

Protect the surrounding plumbing the same way as any other workload.

• Access. Allow bedrock:InvokeModel only for the model ARNs a role needs.
• Network. Reach the Bedrock runtime through a VPC interface endpoint so traffic stays off the internet.
• Logging. Turn on model invocation logging to S3 or CloudWatch Logs, since it is not on by default, and use CloudTrail for the API calls.