xiaoyuyao commented on a change in pull request #687: HDDS-1329. Update 
documentation for Ozone-0.4.0 release. Contributed By Ajay Kumar.
URL: https://github.com/apache/hadoop/pull/687#discussion_r271879985
 
 

 ##########
 File path: hadoop-hdds/docs/content/OzoneSecurityArchitecture.md
 ##########
 @@ -0,0 +1,83 @@
+---
+title: "Ozone Security Overview"
+date: "2019-April-03"
+menu:
+   main:
+       parent: Architecture
+weight: 11
+---
+<!---
+  Licensed to the Apache Software Foundation (ASF) under one or more
+  contributor license agreements.  See the NOTICE file distributed with
+  this work for additional information regarding copyright ownership.
+  The ASF licenses this file to You under the Apache License, Version 2.0
+  (the "License"); you may not use this file except in compliance with
+  the License.  You may obtain a copy of the License at
+
+      http://www.apache.org/licenses/LICENSE-2.0
+
+  Unless required by applicable law or agreed to in writing, software
+  distributed under the License is distributed on an "AS IS" BASIS,
+  WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+  See the License for the specific language governing permissions and
+  limitations under the License.
+-->
+
+# Security in Ozone #
+
+Starting with badlands release (ozone-0.4.0-alpha) ozone cluster can be 
secured against external threats. Specifically it can be configured for 
following security features:
+
+1. Authentication
+2. Authorization
+3. Audit
+4. Transparent Data Encryption (TDE)
+
+## Authentication ##
+
+### Kerberos ###
+Similar to hadoop, Ozone allows kerberos-based authentication. So one way to 
setup identities for all the daemons and clients is to create kerberos keytabs 
and configure it like any other service in hadoop.
+
+### Tokens ###
+Tokens are widely used in Hadoop to achieve lightweight authentication without 
compromising on security. Main motivation for using tokens inside Ozone is to 
prevent the unauthorized access while keeping the protocol lightweight and 
without sharing secret over the wire. Ozone utilizes three types of token:
+
+#### Delegation token ####
+Once client establishes their identity via kerberos they can request a 
delegation token from OzoneManager. This token can be used by a client to prove 
its identity until the token expires. Like Hadoop delegation tokens, an Ozone 
delegation token has 3 important fields:
+
+Renewer:    User responsible for renewing the token.
+Issue date:  Time at which token was issued.
+Max date:    Time after which token can’t be renewed. 
+
+Token operations like get, renew and cancel can only be performed over an 
Kerberos authenticated connection. Clients can use delegation token to 
establish connection with OzoneManager and perform any file system/object store 
related operations like, listing the objects in a bucket or creating a volume 
etc.
+
+#### Block Tokens ####
+Block tokens are similar to delegation tokens in sense that they are signed by 
OzoneManager. But this is where similarity between two stops. Block tokens are 
created by OM (OzoneManager) when a client request involves interaction with 
DataNodes. Unlike delegation tokens there is no client API to request block 
tokens. Instead they are handled transparently for client. Block tokens are 
embedded directly into client request responses. It means that clients don’t 
need to fetch it explicitly from Ozone Manager. This is handled implicitly 
inside ozone  client. Datanodes validates block tokens from clients for every 
client connection.
 
 Review comment:
   Slightly edited version:
   Block tokens are similar to delegation tokens in sense that they are signed 
by OzoneManager. Block tokens are created by OM (OzoneManager) when a client 
request involves interaction with DataNodes such as read/write Ozone keys. 
Unlike delegation tokens there is no client API to request block tokens. 
Instead, they are handed transparently to client along with key/block 
locations. Block tokens are validated by Datanodes when receiving read/write 
requests from clients. Block token can't be renewed explicitly by client. 
Client with expired block token will need to refetch the key/block locations to 
get new block tokens. 
       
    
   

----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
[email protected]


With regards,
Apache Git Services

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to