Amazon Elastic Container Registry – ECR

Elastic Container Registry – ECR

  • Amazon Elastic Container Registry – ECR is a fully managed, secure, scalable, reliable container image registry service.
  • makes it easy for developers to share and deploy container images and artifacts.
  • is integrated with ECS,  EKS, Fargate, and Lambda, simplifying the development to production workflow.
  • eliminates the need to operate your own container repositories or worry about scaling the underlying infrastructure.
  • hosts the images, using S3, in a highly available and scalable architecture, allowing you to deploy containers for the applications reliably.
  • is a Regional service with the ability to push/pull images to the same AWS Region. Images can be pulled between Regions or out to the internet with additional latency and data transfer costs.
  • supports cross-region and cross-account image replication.
  • integrates with AWS IAM and supports resource-based permissions
  • supports public and private repositories.
  • automatically encrypts images at rest using S3 server-side encryption or AWS KMS encryption and transfers the container images over HTTPS.
  • supports tools and docker CLI to push, pull and manage Docker images, Open Container Initiative (OCI) images, and OCI-compatible artifacts.
  • automatically scans the container images for a broad range of operating system vulnerabilities.
  • supports ECR Lifecycle policies that help with managing the lifecycle of the images in the repositories.

Elastic Container Registry - ECR

ECR Components

  • Registry
    •  ECR private registry hosts the container images in a highly available and scalable architecture.
    • A default ECR private registry is provided to each AWS account.
    • One or more repositories can be created in the registry and images stored in them.
    • Repositories can be configured for either cross-Region or cross-account replication.
    • Private Registry is enabled for basic scanning, by default.
    • Enhanced scanning can be enabled which provides an automated, continuous scanning mode that scans for both operating system and programming language package vulnerabilities.
  • Repository
    • An ECR repository contains Docker images, Open Container Initiative (OCI) images, and OCI compatible artifacts.
    • Repositories can be controlled with both user access policies and individual repository policies.
  • Image
    • Images can be pushed and pulled to the repositories.
    • Images can be used locally on the development system, or in ECS task definitions and EKS pod specifications
  • Repository policy
    • Repository policies are resource-based policies that can help control access to the repositories and the images within them.
    • Repository policies are a subset of IAM policies that are scoped for, and specifically used for, controlling access to individual ECR repositories.
    • A user or role only needs to be allowed permission for an action through either a repository policy or an IAM policy but not both for the action to be allowed.
    • Resource-based policies also help grant the usage permission to other accounts on a per-resource basis.
  • Authorization token
    • A client must authenticate to the registries as an AWS user before they can push and pull images.
    • An authentication token is used to access any ECR registry that the IAM principal has access to and is valid for 12 hours.
    • Authorization token’s permission scope matches that of the IAM principal used to retrieve the authentication token.

ECR with VPC Endpoints

  • ECR can be configured to use an Interface VPC endpoint, that enables you to privately access Amazon ECR APIs through private IP addresses.
  • AWS PrivateLink restricts all network traffic between the VPC and ECR to the Amazon network. You don’t need an internet gateway, a NAT device, or a virtual private gateway.
  • VPC endpoints currently don’t support cross-Region requests.
  • VPC endpoints currently don’t support ECR Public repositories.
  • VPC endpoints only support AWS provided DNS through Route 53.

AWS Certification Exam Practice Questions

  • Questions are collected from Internet and the answers are marked as per my knowledge and understanding (which might differ with yours).
  • AWS services are updated everyday and both the answers and questions might be outdated soon, so research accordingly.
  • AWS exam questions are not updated to keep up the pace with AWS updates, so even if the underlying feature has changed the question might not be updated
  • Open to further feedback, discussion and correction.
  1. A company is using Amazon Elastic Container Service (Amazon ECS) to run its container-based application on AWS. The company needs to ensure that the container images contain no severe vulnerabilities. Which solution will meet these requirements with the LEAST management overhead?
    1. Pull images from the public container registry. Publish the images to Amazon ECR repositories with scan on push configured.
    2. Pull images from the public container registry. Publish the images to a private container registry hosted on Amazon EC2 instances. Deploy host-based container scanning tools to EC2 instances that run ECS.
    3. Pull images from the public container registry. Publish the images to Amazon ECR repositories with scan on push configured.
    4. Pull images from the public container registry. Publish the images to AWS CodeArtifact repositories in a centralized AWS account.

References

Amazon_Elastic_Container_Registry_ECR

AWS Resource-based Policies

AWS Resource-based Policies

  • Resource-based policies allow attaching a policy directly to the resource you want to share, instead of using a role as a proxy.
  • Resource-based policies allow granting usage permission to other AWS accounts or organizations on a per-resource basis.
  • Resource-based policy specifies the Principal, in the form of a list of AWS account ID numbers, can access that resource and what they can access.
  • Using cross-account access with a resource-based policy, the User still works in the trusted account and does not have to give up their permissions in place of the role permissions.
  • Users can work on the resources from both accounts at the same time and this can be useful for scenarios e.g. copying objects from one bucket to the other bucket in a different AWS account.
  • Resources that you want to share are limited to resources that support resource-based policies
  • Resource-based policies need the trusted account to create users with permissions to be able to access the resources from the trusted account.
  • Only permissions equivalent to, or less than, the permissions granted to the account by the resource owning account can be delegated.

S3 Bucket Policy

  • S3 Bucket policy can be used to grant cross-account access to other AWS accounts or IAM users in other accounts for the bucket and objects in it.
  • Bucket policies provide centralized, access control to buckets and objects based on a variety of conditions, including S3 operations, requesters, resources, and aspects of the request (e.g. IP address).
  • Permissions attached to a bucket apply to all of the objects in that bucket created and owned by the bucket owner
  • Policies can either add or deny permissions across all (or a subset) of objects within a bucket
  • Only the bucket owner is allowed to associate a policy with a bucket
  • Bucket policies can cater to multiple use cases
    • Granting permissions to multiple accounts with added conditions
    • Granting read-only permission to an anonymous user
    • Limiting access to specific IP addresses
    • Restricting access to a specific HTTP referer
    • Restricting access to a specific HTTP header for e.g. to enforce encryption
    • Granting permission to a CloudFront OAI
    • Adding a bucket policy to require MFA
    • Granting cross-account permissions to upload objects while ensuring the bucket owner has full control
    • Granting permissions for S3 inventory and Amazon S3 analytics
    • Granting permissions for S3 Storage Lens

Glacier Vault Policy

  • S3 Glacier vault access policy is a resource-based policy that can be used to manage permissions to the vault.
  • A Vault Lock policy is a Vault Access policy that can be locked. After you lock a Vault Lock policy, the policy can’t be changed. You can use a Vault Lock Policy to enforce compliance controls.

KMS Key Policy

  • KMS Key Policy helps determine who can use and manage those keys and is a primary mechanism for controlling access to a key.
  • KMS Key Policy can be used alone to control access to the keys.
  • A KMS key policy MUST be used, either alone or in combination with IAM policies or grants to allow access to a KMS CMK.
  • IAM policies by themselves are not sufficient to allow access to keys, though they can be used in combination with a key policy.
  • IAM user who creates a KMS key is not considered to be the key owner and they don’t automatically have permission to use or manage the KMS key that they created.

API Gateway Resource Policy

  • API Gateway resource policies are attached to an API to control whether a specified principal (typically an IAM role or group) can invoke the API.
  • API Gateway resource policies can be used to allow the API to be securely invoked by:
    • Users from a specified AWS account.
    • Specified source IP address ranges or CIDR blocks.
    • Specified virtual private clouds (VPCs) or VPC endpoints (in any account).
  • Resource policies can be used for all API endpoint types in API Gateway: private, edge-optimized, and Regional.

Lambda Function Policy

  • Lambda supports resource-based permissions policies for Lambda functions and layers.
  • Resource-based policy can be used to allow an AWS service to invoke the function on your behalf.
  • Resource-based policies apply to a single function, version, alias, or layer version.

EFS File System Policy

  • EFS supports IAM resource policy using file system policy.
  • EFS evaluates file system policy, along with any identity-based IAM policies to determine the appropriate file system access permissions to grant.
  • An “allow” permission on an action in either an IAM identity policy or a file system resource policy allows access for that action.

ECR Repository policy

    • Repository policies are resource-based policies that can help control access to the repositories and the images within them.
    • Repository policies are a subset of IAM policies that are scoped for, and specifically used for, controlling access to individual ECR repositories.
    • A user or role only needs to be allowed permission for an action through either a repository policy or an IAM policy but not both for the action to be allowed.
    • Resource-based policies also help grant the usage permission to other accounts on a per-resource basis.

SNS Policy

  • SNS policy can be used with a particular topic to restrict who can work with that topic e.g, who can publish messages to it, subscribe to it, etc.
  • SNS policies can grant access to other AWS accounts, or to users within your own AWS account.

SQS Policy

  • SQS policy system lets you grant permission to other AWS Accounts, whereas IAM doesn’t.

AWS Certification Exam Practice Questions

  • Questions are collected from Internet and the answers are marked as per my knowledge and understanding (which might differ with yours).
  • AWS services are updated everyday and both the answers and questions might be outdated soon, so research accordingly.
  • AWS exam questions are not updated to keep up the pace with AWS updates, so even if the underlying feature has changed the question might not be updated
  • Open to further feedback, discussion and correction.

References