# Multi-tenancy work break-down
This doc outlines the key components that requires refactoring to support multi-tenancy model.
Each component is assigned a priority level and an estimated size.
The priority ranges 1 to 3, with 1 being the highest.
The sizes vary from small to large.

## Custom Resource
***priority: 1***
***Size: large***

### Implementation
1. Create both clustered and namespaced CRDs for all components(verifier/policy/store/certStore).
2. Update controllers to support mapping from namespace to components(verifier/policy/store/certStore).
3. Refactor cosign verifier and CertStore so that cosign keys can be configured through CRs.

## External data request
***priority: 1***
***size: small***

### Implementation
1. Add namespace field to the external data request from GK to Ratify.
2. If namespace field is not specified, use the global CRs which is the current behavior, therefore making it backward-compatible.

## Ratify core workflow
***priority: 1***
***size: medium***

### Implementation
1. Update executor workflow to apply namespaced or global verifier/store/policy/certStore dynamically.
2. Stop loading config.json when init Ratify.

## Cache
***priority: 1***
***size: medium***

### Implementation
1. Add namespace prefix to in-memory cache keys.
2. Add namespace prefix to distributed cache keys.
3. [optional] Configure [ACL](https://redis.io/docs/management/security/acl/) to restrict access by namespace.

## Log
***priority: 2***
***size: small***

### Implementation
1. Add namespace field to all Ratify logs.

## Metrics
***priority: 2***
***size: small***

### Implementation
1. Add namespace as a new lable to all metrics.

## File System
***priority: 3***
***size: medium to large***

### Implementation
1. [optional] Separate local_oras_cache by namespace.
2. [optional] Separate downloaded plugin path by namespace.

## Rate limiter
***priority: 3***
***size: medium***

### Implementation
1. [optional] Add rate limiter to handler so that Ratify supports throttling at tenant level.