CSE Key Selection Rules
Last updated
Last updated
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?"
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:
Scenario: Acme Corp has a single Company-Prod Workspace. They want:
Setup in Oten KMS:
Result:
Scenario: The Legal department wants different keys for different types of content:
Setup in Oten KMS:
Result:
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.
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.
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.
In the Company-Prod Workspace, create two CMKs:
Executive-Key — for executive-encrypted content.
Company-Default-Key — set as the Workspace Default Key.
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.
Legal documents in Google Drive should use a Legal-Docs-Key.
Confidential calendar events should use a Legal-Calendar-Key.
In the Legal-Prod Workspace, create the keys and set a default.
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.
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.
Create CSE Key Selection Rules:
Access Oten KMS menu Google CSE → CSE Key Rules → Create new rule
Rule 2: Application = Google Calendar → use Legal-Calendar-Key.
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
