Return-Path: X-Original-To: apmail-hbase-user-archive@www.apache.org Delivered-To: apmail-hbase-user-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 22AE89100 for ; Sat, 20 Dec 2014 07:43:39 +0000 (UTC) Received: (qmail 2807 invoked by uid 500); 20 Dec 2014 07:43:35 -0000 Delivered-To: apmail-hbase-user-archive@hbase.apache.org Received: (qmail 2740 invoked by uid 500); 20 Dec 2014 07:43:35 -0000 Mailing-List: contact user-help@hbase.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@hbase.apache.org Delivered-To: mailing list user@hbase.apache.org Received: (qmail 2728 invoked by uid 99); 20 Dec 2014 07:43:34 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 20 Dec 2014 07:43:34 +0000 X-ASF-Spam-Status: No, hits=1.5 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of esteban@cloudera.com designates 209.85.217.173 as permitted sender) Received: from [209.85.217.173] (HELO mail-lb0-f173.google.com) (209.85.217.173) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 20 Dec 2014 07:43:29 +0000 Received: by mail-lb0-f173.google.com with SMTP id z12so1877719lbi.18 for ; Fri, 19 Dec 2014 23:42:23 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:content-type; bh=m22ib/2eDkQumHo5Ckk4O+9fC1pkSeEDMLgK0ncj/PA=; b=bVJXPt9+mygzENv6BWPDUNqzbtxYixtY9mKWLCVgnIVB6cpIatj2kcS+CQypUcflTf kGo5p1YjWlgK0LXm0Q9fUIKMwUQyv4Vh6eH+ya7cMypEq6bW/hHdmt6qBBilIr3D6m6i jXpulCsM4YXmSVQP+F6LC6qlkrBJDXXRPraczSecTJvU1/HmWa6/zvXDqPkzoij1e9IF e9Uf99D1+DGP2+P3XVRnErYCOjrnzifyI4LNEg6e6N4OMxJqlyt8bLf7YYjBWQbC/AVF byPnnrn62FSM/A2cxTaLQSm2hLlGmJOlVMb3g5ZJjDIABEozKZjtVmO3JDruirrVcf1h Fgig== X-Gm-Message-State: ALoCoQl69cr0OKt7/ciosZ2tbbqLpKlobQcVc2PFNE1mrv69GUQrL53+9feLwWhu/IBCh5W2SfFt X-Received: by 10.152.205.75 with SMTP id le11mr6358485lac.20.1419061342777; Fri, 19 Dec 2014 23:42:22 -0800 (PST) MIME-Version: 1.0 Received: by 10.25.144.146 with HTTP; Fri, 19 Dec 2014 23:42:06 -0800 (PST) In-Reply-To: References: From: Esteban Gutierrez Date: Fri, 19 Dec 2014 23:42:06 -0800 Message-ID: Subject: Re: ACLs/Quotas for HBase structures To: "user@hbase.apache.org" Content-Type: multipart/alternative; boundary=001a11349ff8404b88050aa0f7f6 X-Virus-Checked: Checked by ClamAV on apache.org --001a11349ff8404b88050aa0f7f6 Content-Type: text/plain; charset=UTF-8 Hello Manoj, Thats a very interesting requirement, unfortunately the existing HBase directory structure needs to be owned by the user that started HBase (usually the 'hbase' user) and HBase will handle all the permissions and ACL rules without exposing details from HDFS to the client API. Even if you change the ownership of Hfiles under a specific namespace or table, compactions or splits will create new files as the HBase superuser. Also, running multiple HBase clusters under the same HDFS cluster to go around this limitation should be avoided since it can make things really hard to manage. Regarding the quota requirement, probably HBASE-8410/HBASE-11999 (work in progress) will be the best option in order to support quotas in a reliable way. Keep in mind that using HDFS quotas with HBase doesn't work well since compactions and splits can increase the space utilization beyond the quota sometimes and that could trigger failures in the Region Servers. Probably your only option for now is to monitor the namespace utilization, use Kerberos for authentication and specify a set of ACL rules that will guarantee that users cannot access namespaces that are not allowed to. cheers, esteban. -- Cloudera, Inc. On Fri, Dec 19, 2014 at 10:31 PM, Manoj Murumkar wrote: > > Folks, > > We are trying to control space usage and manage security at HBase namespace > level. Think of it in terms of a RDBMS (database and superuser for a > database). Is there a simple way to do this? > > This is what I have in mind. Does it make sense? > > > - Space quotas: Namespace is managed under > /apps/hbase/data/data/ > directory. We'll use "dfsadmin -setQuota" to set appropriate quotas. > - Make owner of /apps/hbase/data/data/ directory > in hdfs. > > > Thanks for any pointers from folks who have done this kind of thing. > Appreciate the time. > > Manoj > --001a11349ff8404b88050aa0f7f6--