When using KS3, you need an AccessKey (an ASCII string of 20 characters) and a SecretKey (an ASCII string of 40 characters) issued to you by KS3. AccessKey is used to identify the identity of a customer. SecretKey is stored as a private key on the customer’s server and is not transmitted across the network. SecretKey is usually used as the key to calculate the signature of a request, so as to ensure that the request comes from the specified customer. With AccessKey for identification, plus SecretKey for digital signature, you can complete application access and authentication/authorization.
Region indicates the physical location of a KS3's data center. Users can, based on fees, request sources and etc., select an appropriate region to create Buckets. Generally, regions closer to the user will have faster access speeds. Region is specified when a Bucket is created. Once specified, it cannot be changed. All Objects under this Bucket are stored in the corresponding data center. Currently, it is not supported for an Object to specify its region.
Endpoint represents the access domain name for KS3’ external services. KS3 provides external services in the form of HTTP RESTful API. When accessing different Regions, you need different domain names. When accessing the same Region through intranet and extranet, the Endpoints required are different. For example, for the Region of Beijing, the extranet’s Endpoint is ks3-cn-beijing.ksyun.com, and the intranet’s Endpoint is ks3-cn-beijing-internal.ksyun.com.
KS3 provides a virtual storage space for users. In this virtual space, each user can own one or more Buckets.
Bucket is a container to store Objects. All Objects must be stored in a specific Bucket. Each user can create up to 50 Buckets, and each Bucket can store an unlimited number of Objects. Buckets cannot be nested, i.e., only Objects can be stored in a Bucket, and a Bucket cannot be stored in another Bucket. Objects under a Bucket are at the same level. Buckets’ names are globally unique, with the same naming rules as DNS:
In KS3, the basic data unit operated by users is Object. A single Object is allowed to store 0-50TB of data. Object contains keys and data. The key is the name of Object; and the data is the data of Object. The key is UTF-8 encoded, and its length after encoded shall not exceed 1024 bytes.
It is the name of Object and is UTF-8 encoded. And the length after encoded shall not exceed 1024 bytes. The key may contain slashes. When a key has a slash, a directory structure will be automatically organized in the console.
KS3 uses ACL (access control list) to facilitate users to manage the access permissions of Buckets and Objects. Each Bucket and Object has an ACL. ACL defines which users are granted the access permissions as well as the types of access. After KS3 receives a request for certain resources, it will check against the corresponding ACL to decide whether the requestor has the required access permissions.
The following table lists the permission sets that KS3 supports in ACL. Please note: for Object ACLs and Bucket ACLs, the ACL permission set is the same. But as the case may be (for Bucket ACL or Object ACL), these ACL will grant permissions specific to Bucket or Object operations. The following table lists the permissions and describes their meanings in the context of Bucket and Object permissions.
|ACL permissions||Authorization for Bucket||Authorization for Object|
|READ||Allow the authorized person to list the Objects in the Bucket.||Allow the authorized person to read the Object data and its metadata.|
|WRITE||Allow the authorized person to create, overwrite and delete any Object in the Bucket.||N.A.|
|FULL_CONTROL||Grant to the authorized person the READ and WRITE permissions in the Bucket||Grant to the authorized person the READ permissions on the Object|
As seen from the table above, ACL allows only a limited number of permissions to be granted. Each of these permissions allows one or more KS3 operations. The following table shows how to map ACL permissions to the corresponding access policy permissions. ACL is primarily used to grant basic read/write permissions, and this is similar to the permissions of file systems.
|ACL permissions||Corresponding access policy when Bucket grants ACL permissions||Corresponding access policy when Objet (file object) grants ACL permissions|
|READ||List Bucket,List Multipart Upload||Get Object,Head Object, List Parts|
|WRITE||Put Object, Post Object, Put Object Copy, Upload Part Copy,Delete Object,Initiate Multipart Upload, Upload Part, Complete Multipart Upload, Abort Multipart Upload,Restore Object||N.A.|
|FULL_CONTROL||Equivalent to granting the READ and WRITE ACL permissions.||Equivalent to granting the READ ACL permissions.|
KS3 supports a series of predefined authorizations, called preset ACL. Each preset ACL has a predefined set of grantees and permissions. The following table lists a series of preset ACLs and associated predefined authorizations.
|Preset ACL||Applicable for||Preset ACL permissions|
|private||Bucket and Object||The owner will get FULL_CONTROL. Others have no access permission (by default).|
|public-read||Bucket and Object||The owner will get FULL_CONTROL. Others (including the anonymous users) will have READ access permission.|
|public-read-write||Bucket and Object||The owner will get FULL_CONTROL. Others (including the anonymous users) will have READ and WRITE access permission. Granting this permission on Bucket is generally not recommended.|
Logging configuration for Bucket and Object. After logging is configured for a Bucket, the operation logs of the Bucket will be automatically uploaded to the specified Bucket every day.