hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Josh Elser <els...@apache.org>
Subject Re: [DISCUSS] Plan to avoid backup/restore removal from 2.0
Date Tue, 14 Nov 2017 20:57:14 GMT
On 11/14/17 3:04 PM, Mike Drob wrote:
> I don't think the second part of my email ever got addressed.
> 
>> I see  "HBase Backup/Restore Phase 3: Security"[1] resolved as "Later"
> and claims that it will be implemented in the client, both of which make me
> uncomfortable. Security Later is a general bad practice, and it is very
> rarely correct to rely on client-side security for anything.
>> Is there another issue that covers security? Do we rely completely on
> HDFS security here for more than just the DistCP? What kind of testing has
> been done with security, do we have assurances that the backups aren't
> accidentally exposing tables to the world?

"Security" as you phrase is pretty open ended, no? The current security 
model is based around the filesystem permissions and the enforcement of 
an HBase superuser to execute the necessary service operations behind 
the BackupAdmin "facade" (e.g. WAL roll procedure execution, snapshot 
creation, snapshot restore, update hbase:backup are the HBase client 
actions actually being performed). That's the state of what it is right 
now and, yes, it does rely on the filesystem backups are sent to (e.g. 
HDFS, S3, Isilon, WASB) are properly secured. We certainly don't want to 
be testing correctness of those systems in HBase.

I can see a small section on the documentation update I've already been 
hacking on to include details on the issue "We can't help you secure 
where you put the data". Given how many instances of "globally readable 
S3 bucket" I've seen recently, this strikes me as prudent.

The final issue then is about the backup containing other table's data 
-- somehow a backup would reference data from another table than the one 
the admin intended to access. For full backups, this is out of scope 
(the full backup is relying on Snapshots -- we shouldn't be testing 
correctness of Snapshots via B&R). For incremental backups, specifically 
when we're filtering WALs, this is a concern. Thankfully, it's an 
analogous problem to "correctness". We have unit test coverage in this 
area already, and we should get good coverage in the up-coming 
integration test.

Does that help paint a better picture, Mike? Have I missed or glossed 
over any points?

Mime
View raw message