CSE Key Selection Rules (Within a Workspace)

Concept

Once a request reaches a Workspace (via Routing Rules), the CSE Key Selection Rules determine which specific key (CMK) is used for that request. This allows you to assign different keys to different users or applications — all within the same Workspace.

This is the layer that determines: "This user is creating an encrypted Google Doc — which key should encrypt it?" or "This user is opening an encrypted file — which key should decrypt it?"

How It Works

CSE Key Selection Rules use conditions — similar in structure to Organization Routing Rules — but their scope is within a single Workspace. Each rule evaluates conditions against the incoming request and selects the appropriate key.

Available condition types (same as Routing Rules):

• User email: Match specific users or email domains to specific keys.

• Application: Route Drive, Meet, or Calendar requests to different keys.

• Request time: Optionally match based on when the request is made.

When a request matches a rule, the key specified in that rule is used. If no rule matches, the Workspace Default Key is used as fallback.

Sequence Diagram — Key Selection within a Workspace:

Advantages

• Per-user key isolation: Different users within the same Workspace can use different keys — executives use one key, regular staff use another.

• Per-app key separation: Use one key for Google Drive encryption and a different key for Google Meet, within the same Workspace.

• Flexible rules: Combine conditions (user email + application) to create precise key assignments.

• Default fallback: A Workspace Default Key ensures all requests are handled even without specific rules.

When To Use This

• You want different users in the same Workspace to encrypt/decrypt with different keys (e.g., executives vs. regular employees).

• You want to use separate keys per Google app — one key for Drive documents, another for Meet recordings.

• You need granular key assignment without creating additional Workspaces.

Example: Assigning Keys by User Role within a Workspace

Scenario: Acme Corp has a single Company-Prod Workspace. They want:

• Executives (ceo@acme.com, cfo@acme.com) to use a dedicated high-security key for all their encrypted content.

• All other employees to use the default company key.

Setup in Oten KMS:

1. In the Company-Prod Workspace, create two CMKs:

   • Executive-Key — for executive-encrypted content.

   • Company-Default-Key — set as the Workspace Default Key.

   
2. Create CSE Key Selection Rules:

   • Access Oten KMS menu Google CSE → CSE Key Rules → Create new rule

   

   • Rule 1: User email = ceo@acme.com → use Executive-Key.

   

   • Rule 2: User email = cfo@acme.com → use Executive-Key.

   

   • Set Default Google CSE Key

     

Result:

• ceo@acme.com creates an encrypted Google Doc → matched by Rule 1 → encrypted with Executive-Key.

• employee@acme.com creates an encrypted Google Sheet → no rule matched → encrypted with Company-Default-Key.

• cfo@acme.com starts an encrypted Google Meet → matched by Rule 2 → encrypted with Executive-Key.

Example: Separating Keys by Google App

Scenario: The Legal department wants different keys for different types of content:

• Legal documents in Google Drive should use a Legal-Docs-Key.

• Confidential calendar events should use a Legal-Calendar-Key.

Setup in Oten KMS:

1. In the Legal-Prod Workspace, create the keys and set a default.

2. Create CSE Key Selection Rules:

   • Access Oten KMS menu Google CSE → CSE Key Rules → Create new rule

   • Rule 1: Application = Google Drive → use Legal-Docs-Key.

   • Rule 2: Application = Google Calendar → use Legal-Calendar-Key.

Result:

• A lawyer creates an encrypted contract in Google Docs → matched by Rule 1 → encrypted with Legal-Docs-Key.

• A lawyer creates an encrypted Calendar event for a case meeting → matched by Rule 2 → encrypted with Legal-Calendar-Key.

• A lawyer starts an encrypted Google Meet → no rule matched → uses the Workspace Default Key.