You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: hadoop-hdds/docs/content/OzoneSecurityArchitecture.md
+31-12Lines changed: 31 additions & 12 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -32,60 +32,79 @@ Starting with badlands release (ozone-0.4.0-alpha) ozone cluster can be secured
32
32
4. Transparent Data Encryption (TDE)
33
33
34
34
## Authentication ##
35
+
35
36
### Kerberos ###
36
37
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.
37
38
38
39
### Tokens ###
39
40
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:
40
41
41
42
#### Delegation token ####
43
+
42
44
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:
43
45
44
-
Renewer: User responsible for renewing the token.
45
-
Issue date: Time at which token was issued.
46
-
Max date: Time after which token can’t be renewed.
46
+
1.**Renewer**: User responsible for renewing the token.
47
+
2.**Issue date**: Time at which token was issued.
48
+
3.**Max date**: Time after which token can’t be renewed.
47
49
48
50
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.
49
51
50
52
#### Block Tokens ####
51
-
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.
53
+
54
+
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.
55
+
56
+
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.
57
+
52
58
#### S3Token ####
59
+
53
60
Like block tokens S3Tokens are handled transparently for clients. It is signed by S3secret created by client. S3Gateway creates this token for every s3 client request. To create an S3Token user must have a S3 secret.
54
61
55
62
### Certificates ###
56
63
Apart from kerberos and tokens Ozone utilizes certificate based authentication for Ozone service components. To enable this, SCM (StorageContainerManager) bootstraps itself as an Certificate Authority when security is enabled. This allows all daemons inside Ozone to have an SCM signed certificate. Below is brief descriptions of steps involved:
57
-
Datanodes and OzoneManagers submits a CSR (certificate signing request) to SCM.
58
-
SCM verifies identity of DN (Datanode) or OM via Kerberos and generates a certificate.
59
-
This certificate is used by OM and DN to prove their identities.
60
-
Datanodes use OzoneManager certificate to validate block tokens. This is possible because both of them trust SCM signed certificates. (i.e OzoneManager and Datanodes)
64
+
65
+
1. Datanodes and OzoneManagers submits a CSR (certificate signing request) to SCM.
66
+
2. SCM verifies identity of DN (Datanode) or OM via Kerberos and generates a certificate.
67
+
3. This certificate is used by OM and DN to prove their identities.
68
+
4. Datanodes use OzoneManager certificate to validate block tokens. This is possible because both of them trust SCM signed certificates. (i.e OzoneManager and Datanodes)
61
69
62
70
## Authorization ##
63
-
Ozone provides a pluggable API to control authorization of all client related operations. Default implementation allows every request. Clearly it is not meant for production environments. To configure a more fine grained policy one may configure Ranger plugin for Ozone. Since it is a pluggable module clients can also implement their own custom authorization policy and configure it using [ozone.acl.authorizer.class].
71
+
Ozone provides a pluggable API to control authorization of all client related operations. Default implementation allows every request. Clearly it is not meant for production environments. To configure a more fine grained policy one may configure Ranger plugin for Ozone. Since it is a pluggable module clients can also implement their own custom authorization policy and configure it using `ozone.acl.authorizer.class`.
64
72
65
73
## Audit ##
74
+
66
75
Ozone provides ability to audit all read & write operations to OM, SCM and Datanodes. Ozone audit leverages the Marker feature which enables user to selectively audit only READ or WRITE operations by a simple config change without restarting the service(s).
76
+
67
77
To enable/disable audit of READ operations, set filter.read.onMatch to NEUTRAL or DENY respectively. Similarly, the audit of WRITE operations can be controlled using filter.write.onMatch.
68
78
69
79
Generating audit logs is only half the job, so Ozone also provides AuditParser - a sqllite based command line utility to parse/query audit logs with predefined templates(ex. Top 5 commands) and options for custom query. Once the log file has been loaded to AuditParser, one can simply run a template as shown below:
Similarly, users can also execute custom query using:
83
+
84
+
```bash
73
85
ozone auditparser <path to db file> query "select * from audit where level=='FATAL'"
86
+
```
74
87
75
88
## Transparent Data Encryption ##
89
+
76
90
Ozone TDE setup process and usage are very similar to HDFS TDE. The major difference is that Ozone TDE is enabled at Ozone bucket level when a bucket is created.
77
91
78
92
To create an encrypted bucket, client need to
79
93
80
94
* Create a bucket encryption key with hadoop key CLI (same as you do for HDFS encryption zone key)
81
-
```
95
+
96
+
```bash
82
97
hadoop key create key1
83
98
```
99
+
84
100
* Create an encrypted bucket with -k option
85
-
```
101
+
102
+
```bash
86
103
ozone sh bucket create -k key1 /vol1/ez1
87
104
```
105
+
88
106
After that the usage will be transparent to the client and end users, i.e., all data written to encrypted bucket are encrypted at datanodes.
89
107
90
-
To know more about how to setup a secure Ozone cluster refer to [How to setup secure Ozone cluster]("SetupSecureOzone.md")
108
+
To know more about how to setup a secure Ozone cluster refer to [How to setup secure Ozone cluster]({{< ref "SetupSecureOzone.md" >}})
109
+
91
110
Ozone [security architecture document](https://issues.apache.org/jira/secure/attachment/12911638/HadoopStorageLayerSecurity.pdf) can be referred for a deeper dive into Ozone Security architecture.
Copy file name to clipboardExpand all lines: hadoop-hdds/docs/content/Prometheus.md
+3-3Lines changed: 3 additions & 3 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -21,7 +21,7 @@ menu:
21
21
limitations under the License.
22
22
-->
23
23
24
-
[Prometheus](https://prometheus.io/) is an open-source monitoring server developed under under the [Cloud Native Foundation](Cloud Native Foundation).
24
+
[Prometheus](https://prometheus.io/) is an open-source monitoring server developed under under the [Cloud Native Computing Foundation](https://www.cncf.io/).
25
25
26
26
Ozone supports Prometheus out of the box. The servers start a prometheus
27
27
compatible metrics endpoint where all the available hadoop metrics are published in prometheus exporter format.
GET Object | implemented | Range headers are not supported
86
-
Multipart Uplad | not implemented |
86
+
Multipart Uplad | implemented |Except the listing of the current MultiPartUploads.
87
87
DELETE Object | implemented |
88
88
HEAD Object | implemented |
89
89
90
90
91
91
## Security
92
92
93
-
Security is not yet implemented, you can *use* any AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY
93
+
If security is not enabled, you can *use***any** AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY
94
94
95
-
Note: Ozone has a notion for 'volumes' which is missing from the S3 Rest endpoint. Under the hood S3 bucket names are mapped to Ozone 'volume/bucket' locations (depending on the given authentication information).
95
+
If security is enabled, you can get the key and the secret with the `ozone s3 getsecret` command (*kerberos based authentication is required).
**Note**: Ozone has a notion for 'volumes' which is missing from the S3 Rest endpoint. Under the hood S3 bucket names are mapped to Ozone 'volume/bucket' locations (depending on the given authentication information).
96
117
97
118
To show the storage location of a S3 bucket, use the `ozone s3 path <bucketname>` command.
0 commit comments