Using KS3, you need the AccessKey (an ASCII string of 20 characters in length) and the SecretKey (an ASCII string of 40 characters in length) issued by KS3 to you. AccessKey is used to identify the identity of the client. The SecretKey is stored as a private key in the form of client server and is not passed in the network. The SecretKey is usually used as the key to calculate the signature of the request to ensure that the request is from the specified customer. Use AccessKey for identity recognition and SecretKey for digital signature to complete application access and authentication authorization.
Region represents the physical location of the data center of KS3. You can select the appropriate region to create a bucket based on the cost and request source. Generally speaking, regions that are closer to users are faster to access.
Region is specified when bucket is created. Once specified, it cannot be changed. All objects in this bucket are stored in the corresponding data center. Currently, region settings at the object level are not supported.
Endpoint indicates the domain name of KS3's external service. KS3 provides external services in the form of HTTP RESTful API. When accessing different regions, different domain names are required. The endpoint required to access the same region through intranet and extranet is also different. For example, the external endpoint of Beijing region is ks3-cn-beijing.ksyun.com, and the internal endpoint is ks3-cn-beijing-internal.ksyun.com. Please refer to Correspondence between Endpoint and Region.
The virtual bucket provided by KS3 to users, in which each user can have one or more buckets.
Bucket is a container for objects. All objects must be stored in a specific bucket. Each user can create up to 50 buckets, and each bucket can hold an unlimited number of objects. Buckets cannot be nested. Only objects can be stored in each bucket, and buckets can no longer be stored. Objects under a bucket are a flat structure. Bucket names are globally unique and have the same naming rules as DNS:
In KS3, the basic data unit of user operation is object. A single object can store 0-50TB of data. Object contains key and data. Where key is the name of the object and data is the data of the object. The key is encoded by UTF-8, and the encoded length cannot exceed 1024 bytes.
That is, the name of the object. The key is encoded in UTF-8, and the encoded length cannot exceed 1024 bytes. The key can have a slash. When the key has a slash, it will be automatically organized into a directory structure in the console.
KS3 uses ACL (access control list) to facilitate users to manage access rights of bucket and object. Each bucket and object has an ACL. ACL defines which users are granted access rights and types of access. After receiving a request for a resource, KS3 will check the corresponding ACL to verify whether the requester has the required access rights.
The following table lists the permission sets that KS3 supports in ACLS. Note that for object ACLS and bucket ACLS, the ACL permission set is the same. However, depending on the context (bucket ACL or object ACL), these ACL permissions grant specific permissions for bucket or object operations. The following table lists the licenses and describes their meanings in the bucket and object license contexts.
|ACL Authority||Authorize Bucket||Authorize Object|
|READ||Allow authorized persons to list objects in buckets||Allow the authorized person to read object data and its metadata|
|WRITE||Allow the authorized person to create, overwrite and delete any object in the bucket||Not applicable|
|FULL_CONTROL||Grant READ and WRITE permission to the authorized person on the bucket||Grant READ permission to the authorized person on the object|
As you can see from the above figure, ACLS are only allowed to grant a limited number of permissions. Each of these permissions allows one or more KS3 operations. The following table shows how each ACL permission is mapped to the corresponding access policy permission. ACL is mainly used to grant basic read / write permissions, similar to file system permissions.
|ACL Authority||The corresponding access policy when bucket grants ACL permission||The corresponding access policy when objetc grants ACL permission|
|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||Not applicable|
|FULL_CONTROL||Equivalent to granting read and write ACL permissions||Equivalent to granting read ACL permission|
KS3 supports a series of predefined authorizations, called default ACLS. Each default ACL has a predefined set of licensees and permissions. The following table lists a series of preset ACLS and associated predefined authorizations.
|Preset ACL||Apply to||Preset ACL permissions|
|private||Bucket and Object||The owner will get FULL_CONTROL. Others do not have access (default).|
|public-read||Bucket and Object||The owner will get FULL_CONTROL. Others (including anonymous users) will have READ access.|
|public-read-write||Bucket and Object||The owner will get FULL_CONTROL. Others, including anonymous users, will have READ and WRITE access. It is generally not recommended to grant this permission on a bucket.|
Log configuration for bucket and object. After the bucket is configured with Logging, the operation log of the bucket will be automatically uploaded to the specified bucket every day.