Diagram which depicts how security works in pravega. (need more help for this)

This section describes the various default settings and configuration options for how users or processes authenticate to the product subsystems.
Pravega supports pluggable authentication and authorization, The custom implementation performs the implementation of the AuthHandler interface, Administrators and users are allowed to implement their own Authorization/Authentication plugins. Multiple plugins of such kind can exist together. The implementation of plugin follows the Java Service Loader approach. The required Jars for the custom implementation needs to be located in the CLASSPATH to enable the access for Pravega Controller for implementation.

Login security including the topics of login banners, usually presenting legal disclaimers and other usage and privacy policies, failed login behaviour, and account lockout options. (need more help for this)

(need to tell about privacy policies)

(need to tell about failed login behaviour, no. of failed login steps before the exit behaviour is triggered, account lockout steps)

(users or role which can generate and remove emergency lockout behaviour, description of this behaviour, how to lock out one or more users etc)

Pravega supports pluggable authentication and authorization (referred to as auth for short). For details please see Pravega Authentication.

By default, the PasswordAuthHandler plugin is installed on the system. To use the default PasswordAuthHandler plugin for auth, the following steps can be followed:

1. Create a file containing <user>:<password>:<acl>; with one line per user. Delimiter should be : with ; at the end of each line. Use the PasswordCreatorTool to create a new file with the password encrypted. Use this file when creating the secret in next step.

Sample encrypted password file:

$ cat userdata.txt
admin:353030303a633132666135376233353937356534613430383430373939343839333733616463363433616532363238653930346230333035393666643961316264616661393a3639376330623663396634343864643262663335326463653062613965336439613864306264323839633037626166663563613166333733653631383732353134643961303435613237653130353633633031653364366565316434626534656565636335663666306465663064376165313765646263656638373764396361:*,READ_UPDATE;

2. Create a kubernetes secret with this file:

$ kubectl create secret generic password-auth \
  --from-file=./userdata.txt \

Ensure secret is created:

$ kubectl describe secret password-auth

Name:         password-auth
Namespace:    default
Labels:       <none>
Annotations:  <none>

Type:  Opaque

Data
====
userdata.txt:  418 bytes

3. Specify the secret names in the authentication block and these parameters in the options block.

apiVersion: "pravega.pravega.io/v1alpha1"
kind: "PravegaCluster"
metadata:
  name: "example"
spec:
  authentication:
    enabled: true
    passwordAuthSecret: password-auth
...
  pravega:
    options:
      controller.auth.enabled: "true"
      controller.auth.userPasswordFile: "/etc/auth-passwd-volume/userdata.txt"
      controller.auth.tokenSigningKey: "secret"
      autoScale.authEnabled: "true"
      autoScale.tokenSigningKey: "secret"
      pravega.client.auth.token: "YWRtaW46MTExMV9hYWFh"
      pravega.client.auth.method: "Basic"

...

pravega.client.auth.method and pravega.client.auth.token represent the auth method and token to be used for internal communications from the Segment Store to the Controller. If you intend to use the default auth plugin, these values are:

pravega.client.auth.method: Basic
pravega.client.auth.token: Base64 encoded value of <username>:<pasword>,

where username and password are credentials you intend to use.

Note that Pravega operator uses /etc/auth-passwd-volume as the mounting directory for secrets.

(Describe default/pre-loaded accounts and their purpose within the product or subsystem)

(Describe default/pre-loaded credentials)

(Describe how to disable or remove local accounts.)

(Describe options for managing credentials within the product.)

(Describe settings for security local credentials)

(Describe customer options for creating password complexity and strength rules, including any limitations.)

(How to configure a connection or integration to an external system)

(Access control options for external systems accessing the product or subsystem)

(How to provide credentials to use to authenticate to the external system)

(Options for securing credentials used to connect to remote systems)

Pravega implement a pluggable authorization model. The authorization kicks in only with interactions with the controller through GRPC or REST. Once the request is authorized, controller generates a token. This token will be presented to the SegmentStore. Once the token is validated, SegmentStore will assume that the interactions have already been approved by the controller. The authorizer model returns whether the user is authorized as well as a string which represents the user identity. Advantage of this will mean that we do not have authorization happening twice, once with the controller and then with segmentstore. This will also take the authorization part away from the performance critical path.

Token is used to share authorization information between Pravega controller and SegmentStore. The token follows the JWT (JSON Web Token) format closely. https://tools.ietf.org/html/rfc7519 It is signed by a symmetric key shared between controller and SegmentStore. More details about how JWT tokens are signed can be found here: https://tools.ietf.org/html/rfc7515. A token consists of the resource identifier. SegmentStore has the responsibility of validating the token. It also converts the token from controller primitives (stream/scope) to SegmentStore primitives (segments). SegmentStore validates signature of this token, validates that the resource id requested matches the one specified in the token, validates the lifetime of the token and if it matches, performs the given operation.

Jason Web Token format and implementation gives an efficient way of signing and encrypting claim based tokens. This is a widely used format and has advanced features in-built like token expiry etc which will be useful in the context of Pravega.

Tokens are short lived. Controller controls their lifetime using the 'exp' claim. https://tools.ietf.org/html/rfc7519#section-4.1.4. The expiration time is checked before start of a given SegmentStore operation. In case an expired token is observed, SegmentStore returns appropriate error to the client. The client can interact with controller and receive a new token after controller reauthenticates it.

You can optionally configure non-default service accounts for the Bookkeeper, Pravega Controller, and Pravega Segment Store pods.

For BookKeeper, set the serviceAccountName field under the bookkeeper block.

...
spec:
  bookkeeper:
    serviceAccountName: bk-service-account
...

For Pravega, set the controllerServiceAccountName and segmentStoreServiceAccountName fields under the pravega block.

...
spec:
  pravega:
    controllerServiceAccountName: ctrl-service-account
    segmentStoreServiceAccountName: ss-service-account
...

If external access is enabled in your Pravega cluster, Segment Store pods will require access to some Kubernetes API endpoints to obtain the external IP and port. Make sure that the service account you are using for the Segment Store has, at least, the following permissions.

kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: pravega-components
  namespace: "pravega-namespace"
rules:
- apiGroups: ["pravega.pravega.io"]
  resources: ["*"]
  verbs: ["get"]
- apiGroups: [""]
  resources: ["pods", "services"]
  verbs: ["get"]
---
kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: pravega-components
rules:
- apiGroups: [""]
  resources: ["nodes"]
  verbs: ["get"]

Replace the namespace with your own namespace.

Create the namespace.

$ kubectl create namespace pravega-io

Update the namespace configured in the deploy/role_binding.yaml file.

$ sed -i -e 's/namespace: default/namespace: pravega-io/g' deploy/role_binding.yaml

Apply the changes.

$ kubectl -n pravega-io apply -f deploy

Note that the Pravega operator only monitors the PravegaCluster resources which are created in the same namespace, pravega-io in this example. Therefore, before creating a PravegaCluster resource, make sure an operator exists in that namespace.

$ kubectl -n pravega-io create -f example/cr.yaml

$ kubectl -n pravega-io get pravegaclusters
NAME      AGE
pravega   28m

$ kubectl -n pravega-io get pods -l pravega_cluster=pravega
NAME                                          READY     STATUS    RESTARTS   AGE
pravega-bookie-0                              1/1       Running   0          29m
pravega-bookie-1                              1/1       Running   0          29m
pravega-bookie-2                              1/1       Running   0          29m
pravega-pravega-controller-6c54fdcdf5-947nw   1/1       Running   0          29m
pravega-pravega-segmentstore-0                1/1       Running   0          29m
pravega-pravega-segmentstore-1                1/1       Running   0          29m
pravega-pravega-segmentstore-2                1/1       Running   0          29m

(we need to mention the ports and protocols in use and default execution mode)

(we need to mention Configuration options to enable endpoint validation)

(we need to mention How to configure or verify the functionality of the product’s firewall)

(we need to mention capabilities for securing application and customer data)

Pravega uses Apache BookKeeper as Tier 1 implementation. Apache Bookkeeper currently does not support encryption of data written to disk.

Pravega can work with different storage options for Tier 2. To use any specific storage option, it is necessary to implement a storage interface. We currently have the following options implemented: HDFS Extended S3 File system (NFS).

Pravega does not encrypt data before storing it in Tier 2. Consequently, Tier 2 encryption is only an option in the case the storage system provides it natively, and as such, needs to be configured directly in the storage system, not via Pravega.

Pravega ensures that all the data in flight can be passed by applying encryption. The different channels present in data integrity section can be configured with TLS and encryption can be enabled for them.

(we need to mention capabilities for securely sanitizing (erasing) customer data)

Client can communicate with Pravega in a more secure way using TLS. To enable this feature, you will first need to create secrets for Controller and Segment Store to make the relevant, sensible files available to the backend pods.

$ kubectl create secret generic controller-tls \
  --from-file=./controller01.pem \
  --from-file=./ca-cert \
  --from-file=./controller01.key.pem \
  --from-file=./controller01.jks \
  --from-file=./password

$ kubectl create secret generic segmentstore-tls \
  --from-file=./segmentstore01.pem \
  --from-file=./ca-cert \
  --from-file=./segmentstore01.key.pem

Then specify the secret names in the tls block and the TLS parameters in the options block.

apiVersion: "pravega.pravega.io/v1alpha1"
kind: "PravegaCluster"
metadata:
  name: "example"
spec:
  tls:
    static:
      controllerSecret: "controller-tls"
      segmentStoreSecret: "segmentstore-tls"
...
  pravega:
    options:
      controller.auth.tlsEnabled: "true"
      controller.auth.tlsCertFile: "/etc/secret-volume/controller01.pem"
      controller.auth.tlsKeyFile: "/etc/secret-volume/controller01.key.pem"
      pravegaservice.enableTls: "true"
      pravegaservice.certFile: "/etc/secret-volume/segmentStore01.pem"
      pravegaservice.keyFile: "/etc/secret-volume/segmentStore01.key.pem"
...

Note that Pravega operator uses /etc/secret-volume as the mounting directory for secrets.

For more security configurations, check here.

In the distributed mode, Controllers and Segment Stores are configured individually. The following sub-sections describe their Transport Layer Security (TLS) and auth (short for authentication and authorization) parameters.

For ease of use, Pravega standalone mode abstracts away some of the configuration parameters of distributed mode. As a result, it has fewer security configuration parameters to configure.

(we need to mention Document other data security features or capabilities, when available)

(Describe capabilities and options for using cryptography in the product.)

(Describe capabilities for use of FIPS 140-2 validated cryptographic modules and settings)

(Describe settings and options for using certificates in the product)

(Provide references to export compliance and other regulatory information customers should be aware of)

(Describe log location(s) and usage)

(Describe options for managing logs in the system.)

(Describe capabilities for securing security-sensitive log contents)

(Describe the format of logs, including timestamp formats, special labels or indicators, and other details customers will need to properly understand security logs.)

(Describe features and options for generating alerts)

(Describe physical ports and interfaces)

(Describe physical security controls in place or that can be applied by customers)

(Describe necessary access to physical devices restricted for service use vs customer use)

(Describe mechanisms in place or that can be applied by customers to protect access to the product physically)

(Provide a reference to or copy of any Statements of Volatility)

(Describe accounts, tools, and other functionality intended as “Maintenance Aids")

(Describe expectations around service access by Dell)

(Identify the types of information transmitted to Dell via a ‘call home’ or serviceability tool that is part of the Dell product)

(Describe the security patching and update policy and behavior and settings that relate to this functionality (if available))

(Describe actions customers must take with respect to security updates)

(Identify how the authenticity and integrity of the distributed product and/or its code (software and firmware) is maintained)

(Describe how a customer can verify the authentication and integrity of the distributed product)