A control panel is a graphical interface that allows users to manage settings and features. They are often found in the context of native apps on desktop or mobile operating systems, where they can be used to configure applications and the operating system itself. Control panels are also found on the web, where they most often manage web applications and infrastructure.
The nature and function of a control panel depends on its purpose. For example, web hosting services often provide control panels which allow you to see an overview of your servers and resources, as well as to create, manage, configure, and delete those resources.
Webmin is one popular web-based control panel that is used for managing Linux-based servers. For more information, please see How To Install Webmin on Ubuntu 20.04.
For information on other control panel software, please look at our Control Panels tag page which has links to relevant tutorials and Q&A.
Use promo code DOCS10 for $10 credit on a new account.
Linode Object Storage allows users to share access to objects and buckets with other Object Storage users. There are two mechanisms for setting up sharing: Access Control Lists (ACLs), and bucket policies. These mechanisms perform similar functions: both can be used to restrict and grant access to Object Storage resources.
In this guide you will learn:
Before You Begin
This guide will use the s3cmd command line utility to interact with Object Storage. For s3cmd installation and configuration instructions, visit our How to Use Object Storage guide.
You’ll also need the canonical ID of every user you wish to grant additional permissions to.
Retrieve a User’s Canonical ID
Follow these steps to determine the canonical ID of the Object Storage users you want to share with:
The following command will return the canonical ID of a user, given any of the user’s buckets:
s3cmd info s3://other-users-bucket
Note
The bucket referred to in this section is an arbitrary bucket on the target user’s account. It is not related to the bucket on your account that you would like to set ACLs or bucket policies on.
There are two options for running this command:
The users you’re granting or restricting access to can run this command on one of their buckets and share their canonical ID with you, or:
You can run this command yourself if you have use of their access tokens (you will need to configure s3cmd to use their access tokens instead of your own).
Run the above command, replacing other-users-bucket with the name of the bucket. You’ll see output similar to the following:
The canonical ID of the owner of the bucket is the long string of letters, dashes, and numbers found in the line labeled ACL, which in this case is a0000000-000a-0000-0000-00d0ff0f0000.
Alternatively, you may be able to retrieve the canonical ID by curling a bucket and retrieving the Owner ID field from the returned XML. This method is an option when both of these conditions are true:
The bucket has objects within it and has already been set to public (with a command like s3cmd setacl s3://other-users-bucket --acl-public).
The bucket has not been set to serve static websites.
Run the curl command, replacing the bucket name and cluster URL with the relevant values:
In the above output, the canonical ID is a0000000-000a-0000-0000-00d0ff0f0000.
ACLs vs Bucket Policies
ACLs and bucket policies perform similar functions: both can restrict or grant access to buckets. ACLs can also restrict or grant access to individual objects, but they don’t offer as many fine-grained access modes as bucket policies.
How to Choose Between ACLs and Bucket Policies
If you can organize objects with similar permission needs into their own buckets, then it’s strongly suggested that you use bucket policies. However, if you cannot organize your objects in this fashion, ACLs are still a good option.
ACLs offer permissions with less fine-grained control than the permissions available through bucket policies. If you are looking for more granular permissions beyond read and write access, choose bucket policies over ACLs.
Additionally, bucket policies are created by applying a written bucket policy file to the bucket. This file cannot exceed 20KB in size. If you have a policy with a lengthy list of policy rules, you may want to look into ACLs instead.
Note
ACLs and bucket policies can be used at the same time. When this happens, any rule that limits access to an Object Storage resource will override a rule that grants access. For instance, if an ACL allows a user access to a bucket, but a bucket policy denies that user access, the user will not be able to access that bucket.
ACLs
Access Control Lists (ACLs) are a legacy method of defining access to Object Storage resources. You can apply an ACL to a bucket or to a specific object. There are two generalized modes of access: setting buckets and/or objects to be private or public. A few other more granular settings are also available.
With s3cmd, you can set a bucket to be public with the setacl command and the --acl-public flag:
s3cmd setacl s3://acl-example --acl-public
This will cause the bucket and its contents to be downloadable over the general Internet.
To set an object or bucket to private, you can use the setacl command and the --acl-private flag:
s3cmd setacl s3://acl-example --acl-private
This will prevent users from accessing the bucket’ contents over the general Internet.
Other ACL Permissions
The more granular permissions are:
Permission
Description
read
Users with can list objects within a bucket
write
Users can upload objects to a bucket and delete objects from a bucket.
read_acp
Users can read the ACL currently applied to a bucket.
write_acp
Users can change the ACL applied to the bucket.
full_control
Users have read and write access over both objects and ACLs.
Setting a permission: To apply these more granular permissions for a specific user with s3cmd, use the following setacl command with the --acl-grant flag:
Substitute acl-example with the name of the bucket (and the object, if necessary), PERMISSION with a permission from the above table, and CANONICAL_ID with the canonical ID of the user to which you would like to grant permissions.
Revoking a permission: To revoke a specific permission, you can use the setacl command with the acl-revoke flag:
Substitute the bucket name (and optional object), PERMISSION, and CANONICAL_ID with your relevant values.
View current ACLs: To view the current ACLs applied to a bucket or object, use the info command, replacing acl-example with the name of your bucket (and object, if necessary):
This policy allows the user with the canonical ID a0000000-000a-0000-0000-00d0ff0f0000, known here as the “principal”, to interact with the bucket, known as the “resource”. The “resource” that is listed (bucket-policy-example) is the only bucket the user will have access to.
Note
The principal (a.k.a. the user) must have the prefix of arn:aws:iam:::, and the resource (a.k.a. the bucket) must have the prefix of arn:aws:s3:::.
The permissions are specified in the Action array. For the current example, these are:
The Action and Principal.AWS fields of the bucket policy are arrays, so you can easily add additional users and permissions to the bucket policy, separating them by a comma. To grant permissions to all users, you can supply a wildcard (*) to the Principal.AWS field.
If you instead wanted to deny access to the user, you could change the Effect field to Deny.
Enable a Bucket Policy
To enable the bucket policy, use the setpolicy s3cmd command, supplying the file name of the bucket policy as the first argument, and the S3 bucket address as the second argument:
You may wish to consult the following resources for additional information on this topic. While these are provided in the hope that they will be useful, please note that we cannot vouch for the accuracy or timeliness of externally hosted materials.
Find answers, ask questions, and help others.
This guide is published under a CC BY-ND 4.0 license.
Use promo code DOCS10 for $10 credit on a new account.
Note
At the highest level of Kubernetes, there exist two kinds of servers, a Master and a Node. These servers can be Linodes, VMs, or physical servers. Together, these servers form a cluster and are controlled by the services that make up the Control Plane.
In this guide you will learn about the Master server, cluster nodes, and the Kubernetes Control Plane.
Kubernetes Master
The Kubernetes Master is normally a separate server responsible for maintaining the desired state of the cluster. It does this by telling the Nodes how many instances of your application it should run and where.
Nodes
Kubernetes Nodes are worker servers that run your application(s). The number of Nodes is determined by the user, and they are created by the user. In addition to running your application, each Node runs two processes:
kubelet receives descriptions of the desired state of a Pod from the API server, and ensures the Pod is healthy, and running on the Node.
kube-proxy is a networking proxy that proxies the UDP, TCP, and SCTP networking of each Node, and provides load balancing. This is only used to connect to Services.
The Control Plane
Together, kube-apiserver, kube-controller-manager, kube-scheduler, and etcd form what is known as the control plane. The control plane is responsible for making decisions about the cluster, and pushing it toward the desired state. kube-apiserver, kube-controller-manager, and kube-scheduler are processes and etcd is a database; all four are run by the Kubernetes Master.
kube-apiserver is the front end for the Kubernetes API server.
kube-controller-manager is a daemon that manages the Kubernetes control loop. For more on Controllers, see the Beginner’s Guide to Kubernetes: Controllers.
kube-scheduler is a function that looks for newly created Pods that have no Nodes, and assigns them a Node based on a host of requirements. For more information on kube-scheduler, consult the Kubernetes kube-scheduler documentation.
Etcd is a highly available key-value store that provides the backend database for Kubernetes. It stores and replicates the entirety of the Kubernetes cluster state. It’s written in Go and uses the Raft protocol which means it maintains identical logs of state changing commands across nodes and coordinates the order in which these state changes occur.
Next Steps
To continue in the Beginner’s Guide to Kubernetes series, visit part 3:
More Information
You may wish to consult the following resources for additional information on this topic. While these are provided in the hope that they will be useful, please note that we cannot vouch for the accuracy or timeliness of externally hosted materials.
Find answers, ask questions, and help others.
This guide is published under a CC BY-ND 4.0 license.