Container Security (Part 2 of 3)

By Ashwin Venugopal -

 



To read part 1 of 3 please click here
To read part 3 of 3 please click here


Azure Container Registry (ACR)

Registry

A container registry is known as a service that stores and distributes container images while providing the users with direct control of their images, with integrated authentication, geo-replication supporting global distribution and reliability for network-close deployments, virtual network and firewall configuration, tag locking, and many other enhanced features.
Besides Docker container images, ACR supports related content artifacts including Open Container Initiative (OCR) image formats.

Security and Access

ACI transfers container's images over HTTPS and supports TLS to secure client connections. Security features of the Premium SKU includes content trust for image tag signing, firewalls and virtual networks to restrict access to the registry. Azure Security Center optionally integrates with ACR to scan images whenever an image is pushed to a registry.

Repository

Container registries manage repositories, collections of container images or other artifacts with the same name but different tags. For example- acr-helloworld:latest, acr-helloworld:v1, acr-helloworld:v2 

Image

A container image or other artifact within a registry is associated with one or more tags, has one or more layers, and is identified by a manifest. Understanding how these components relate to each other can help you manage your registry effectively.

Monitor container activity and user access

The container monitoring solution in Log Analytics can help you view and manage your Docker and Windows container host in a single location. By using Log analytics you can:
  • View detailed audit information that shows commands used with containers.
  • Troubleshoot containers by viewing and searching centralized logs without having to remotely view Docker or Windows hosts.
  • Find containers that may be noisy and consuming access resources on a host.
  • View centralized CPU, memory, storage, network usage and performance information for containers. 
Containers makes it possible to run multiple instances of an application on a single instance of an OS, thereby using resources more efficiently; hence providing agility, streamlined operations, scalability and reduced costs due to resource optimization.

 Authenticate with an Azure Container Registry

There are several ways to authenticate with an ACR, each of which is applicable to one or more registry usage scenarios. The following table lists available authentication methods and recommended scenarios:

Identity

Usage scenario

Details

Azure AD identities including user and service principles.

Unattended push from DevOps, unattended pull to Azure or external services.

Role-based access control- Reader, Contributor, Owner

Individual AD Identity

Interactive push/pull by developers and testers

 

Admin user

Interactive push/pull by individual developers and testers

By default, disabled

 Individual login with Azure AD

When you login by using the az acr login command in the Azure CLI, it (CLI) uses the token created when you executed az login to seamlessly authenticate your session with your registry. To complete the execution flow Docker must be installed and running in your environment which can be used by az acr login to set an Azure Active Directory token in the docker.config file. Once you've logged in this way, your credentials are cached, and subsequent docker commands in your session do not require a username or password.

Service principle

If you assign a service principle to your registry, your application or service can use it for headless authentication. Multiple service principles allow you to define different access for different applications. The available roles for a container registry includes- AcrPull: pull, AcrPush: pull and push, Owner: pull, push, and assign roles to other users.  

Admin account

Each container registry includes an admin user account, which is disabled by default and can be enabled easily. The admin account is provided with two passwords, both of which can be regenerated and allows you to maintain connection to the registry by using one password while you regenerate the other. If the admin account is enabled, you can pass the username and either password to the docker login command when prompted for basic authentication to the registry.


To read part 1 of 3 please click here
To read part 3 of 3 please click here





















Comments

Post a Comment

Popular posts from this blog

Deployment (Part 3)

By Ashwin Venugopal -
Image
  To read part 1, please click  here To read part 2, please click  here Microsoft Monitoring Agent (MMA) MMA is used across multiple Microsoft solutions and has undergone a few name changes as its features and functionality have evolved. If it is being considered to be used, then following areas should be covered during a Microsoft Sentinel deployment project: Consider the timelines and the strategy for a migration to AMA (Azure Monitor Agent) before the MMA end-of-life.  Consider the central deployment and management methodology for MMA. Determine which endpoints are in scope for deployment as these affect the log ingestion volume significantly.  Azure Monitor Agent (AMA) Organizations with MMA as the main Microsoft Sentinel agent should start planning the migration to AMA as soon as possible to avoid a rushed migration. One of the main advantages of AMA is the ability to control the log collection policy centrally and apply different policies against different...
Read more

Deployment (Part 1)

By Ashwin Venugopal -
Image
  To read part 2, please click  here To read part 3, please click  here Azure Resources Microsoft Sentinel needs following resources to be created: Subscription (if a dedicated subscription(s) will be used) Resource group(s) Log Analytics workspace(s) Automation rules/playbook Alert rules Workbooks Microsoft Sentinel offers hundreds of alert rules, workbooks, and automation playbook templates along with hunting scripts. The templates can be used to activate/deploy schedule alerts, create customized dashboards, create automation playbooks and perform threat-hunting activities. Generally, once deployed, the resources created have to be adjusted to match the existing environment, configure local credentials, etc. Methods of deployment: Manual- Administrator can manually configures the Microsoft Sentinel resources with the help of Azure portal. Any manual process has the inherent risks of human operator error, lack of compliance with potential change control procedures, and u...
Read more

Project Resourcing (Part 2)

By Ashwin Venugopal -
Image
  To read part 1, please click  here Engineering - SIEM The SIEM engineers configures Microsoft Sentinel, including Log Analytics, Logic Apps, workbooks, and playbooks. They are also responsible for the following high-level tasks: Initial configuration of Azure tenant, including provisioning required resources, assigning access roles, and configuring workspace parameters like log retention, resource tagging, and blueprints.  Deployment and configuration of syslog/CEF log collection agents in appropriate locations to collect logs from on-premises devices. Generally, it will be joint effort of both system engineer and SIEM engineer, involving configuration and potential troubleshooting.  Working with system owners to enable log forwarding and configuring any required parsing of log data in Log Analytics.  Working with security operations to create and deploy KQL analytic rules to offer detections for SOC/Computer Security Incident Response Team (CSRIT) use. Tuning...
Read more