6.2 KiB
| title | date | summary | weight | icon |
|---|---|---|---|---|
| Securing Ozone | 2019-April-03 | Overview of Ozone security concepts and steps to secure Ozone Manager and SCM. | 1 | tower |
Kerberos
Ozone depends on Kerberos to make the clusters secure. Historically, HDFS has supported running in an isolated secure networks where it is possible to deploy without securing the cluster.
This release of Ozone follows that model, but soon will move to secure by default. Today to enable security in ozone cluster, we need to set the configuration ozone.security.enabled to true and hadoop.security.authentication to kerberos.
| Property | Value |
|---|---|
| ozone.security.enabled | true |
| hadoop.security.authentication | kerberos |
Tokens
Ozone uses a notion of tokens to avoid overburdening the Kerberos server. When you serve thousands of requests per second, involving Kerberos might not work well. Hence once an authentication is done, Ozone issues delegation tokens and block tokens to the clients. These tokens allow applications to do specified operations against the cluster, as if they have kerberos tickets with them. Ozone supports following kinds of tokens.
Delegation Token
Delegation tokens allow an application to impersonate a users kerberos credentials. This token is based on verification of kerberos identity and is issued by the Ozone Manager. Delegation tokens are enabled by default when security is enabled.
Block Token
Block tokens allow a client to read or write a block. This is needed so that data nodes know that the user/client has permission to read or make modifications to the block.
S3Token
S3 uses a very different shared secret security scheme. Ozone supports the AWS Signature Version 4 protocol, and from the end users perspective Ozone's s3 feels exactly like AWS S3.
The S3 credential tokens are called S3 tokens in the code. These tokens are also enabled by default when security is enabled.
Each of the service daemons that make up Ozone needs a Kerberos service principal name and a corresponding kerberos key tab file.
All these settings should be made in ozone-site.xml.
Storage Container Manager
SCM requires two Kerberos principals, and the corresponding key tab files
for both of these principals.
| Property | Description |
|---|---|
| hdds.scm.kerberos.principal | The SCM service principal. e.g. scm/_HOST@REALM.COM |
| hdds.scm.kerberos.keytab.file | The keytab file used by SCM daemon to login as its service principal. |
| hdds.scm.http.kerberos.principal | SCM http server service principal. |
| hdds.scm.http.kerberos.keytab | The keytab file used by SCM http server to login as its service principal. |
Ozone Manager
Like SCM, OM also requires two Kerberos principals, and the
corresponding key tab files for both of these principals.
| Property | Description |
|---|---|
| ozone.om.kerberos.principal | The OzoneManager service principal. e.g. om/_HOST@REALM.COM |
| ozone.om.kerberos.keytab.file | TThe keytab file used by SCM daemon to login as its service principal. |
| ozone.om.http.kerberos.principal | Ozone Manager http server service principal. |
| ozone.om.http.kerberos.keytab | The keytab file used by OM http server to login as its service principal. |
S3 Gateway
S3 gateway requires one service principal and here the configuration values
needed in the ozone-site.xml.
| Property | Description |
|---|---|
| ozone.s3g.authentication.kerberos.principal | S3 Gateway principal. e.g. HTTP/_HOST@EXAMPLE.COM |
| ozone.s3g.keytab.file | The keytab file used by S3 gateway |