This post is an overview of what I have learned about security and scope when working with CloudKit.
Databases
At the top of the silo is a single Cloudkit container and it has three databases: Public, Private and Shared
With this post, I’ll focus on the first two and go into the Shared database in another post
The Public database is one big database that all of the app’s users have access to. The Private database is unique to each user of the app and is tied to that user’s iCloud account. The storage limits of each user’s iCloud account applies to their private database for your app.
Permissions and Security Roles
Each Record Types has a Security setting. A matrix with roles (World, Authenticated, Creator, plus any custom roles you add) and types (create, read, write). By default, create is allowed for Creator and Authenticated. Read is allowed for World, and write is limited to just Creator.
These settings can be changed in the CloudKit dashboard. Each Record Type has its own security role settings (Individual records do NOT have security settings, only the record type).
World is what you would expect, everyone has access.
Creator refers to the creator of a particular record instance (NOT the owner of the CloudKit account).
Authenticated refers to any user who is logged in with their Apple account. No authorization is applied, any and all users with an Apple account will have permission.
Custom allows you to create your own roles in the Security Roles section. After creating a new security role, add users to the role in the User Records section. If your app doesn’t implement discovery, then you will only see users represented as hashes.
You can identify your own hash by creating a record, find it in the CloudKit database, look at the value in the Created By field and find the matching entry in the User Records section.
Security roles only apply to the PUBLIC database. Since the Private database is unique to an app’s user, then that user will be the creator for all the data and subsequently the sole person to read and write to the database.
Zones
Multiple records live in a zone and multiple zones live in a database. The Public database has only the default zone.
While Private databases have a default zone, they are also allowed custom zones. Your application can create and upload custom zones into the database.
The choice of the database and zone will have an effect on the types of remote notifications that are available.
Apple Tutorial Videos
In can be difficult finding answers to questions about CloudKit on the web. But A lot of CloudKit information is covered in the WWDC videos. Here’s a brief description of the videos available and what they cover.
WWDC 2015
What’s New in CloudKit - Session 704
High level overview of working with CloudKit: limits, fees, subscriptions, notifications, and an introduction to the Javascript API
CloudKit Tips and Tricks - Session 715
Descriptions and clarifications of databases
A detailed walkthrough of a CloudKit exchange (emphasis on error handling)
A description of the two types of subscriptions:
• zone subscriptions
• query subscriptions (based on a predicate).
Using CKOperations and batching requests
WWDC 2016
What’s New with CloudKit - Session 226
Improvements to APIs:
• long-live operations
• improved queries across multiple zones
A new Shared database
Overview of zones
Permissions and permission profiles
Deep dive into sharing
CloudKit Best Practices - Session 231
More depth on using CKOperations
Workflow description between client and server
• custom and shared zones
• integration with subscriptions
• remote notifications
• change tokens
Automatic authentication
References between records for one-to-many relationships
More on error handling and query retries
WWDC 2017
Build Better Apps with CloudKit Dashboard - Session 226
Overview of changes to CloudKit dashboard
Tech Talks 2018
GDPR & CloudKit - Session 703