Security in Watson Studio Local
Watson Studio Local comes equipped with an array of security features you can use.
Watson Studio Local uses the following security features:
An administrator can set up SAML2.0 to redirect Watson Studio Local users to sign in securely through your identity provider's login page.
- You can install Watson Studio Local using a private SSH key file for the credentials (instead of a sudo username and password).
- A Watson Studio Local administrator can enable SSHD so that users (using a public/public SSH key pair) can ssh directly to the Watson Studio Local cluster through a secure port.
- If you plan to use your own SSL certificate and private key (both in PEM format) to enable an HTTPS connection to the Watson Studio Local client, you can change the default using the /wdp/utils/change_nginx_cert.sh script.
- If you configure an SMTP service so that Watson Studio Local can email notifications to users and administrators, the SMTP port in the admin settings must be a secure SSL port.
- If you plan to use SSL for Db2 for Linux, UNIX, and Windows or Db2 Warehouse on Cloud connection, select the Use SSL check box for them.
- If you plan to use SSL for a Db2 for Linux, UNIX, and Windows connection that uses a self-signed certificate or a certificate signed by a local certificate authority (CA), you need to import the SSL certificate to the Spark truststore.
- If you plan to use SSL for a Kafka connection, you need a truststore with Certificate Authority (CA) certificate and a keystore with a key pair and certificate that is signed by CA (used to authenticate Spark submit service as a client).
- If you plan to use a secure HDP cluster, you must set up Knox to perform a JWT token based authentication against the Watson Studio Local public certificate. When Watson Studio Local makes a request to a service through Knox, it passes the JWT authentication token of the logged in Watson Studio Local user. Knox verifies the JWT token against the public certificate and sets the Watson Studio Local user as the proxy user for the request.
- Watson Studio Local automatically generates a bearer token when a user signs in, and securely stores information in the user's home directory. This token expires based on the policies defined in the Watson Studio Local cluster. When the user signs out, the stored bearer token is cleared.
- A Watson Studio Local project requires a personal access token to connect to an external Git repository.
- Watson Studio Local provides an encrypted bearer token in the model deployment details that an application developer can use for evaluating models online with REST APIs. The token never expires, and is limited to the model it is associated with.
- Each project release uses one bearer token. Each web service deployment provides a deployment bearer token.
- By default, Watson Studio Local user records are stored in its internal repository database. Alternatively, you can use your own external LDAP server instead.
- A Watson Studio Local administrator can assign User, Admin, or Deployment Admin permissions.
- A Watson Studio Local project administrator can assign Viewer, Editor, or Admin permissions to collaborators.
- Remote data sets created in Watson Studio Local do not create a local copy of the data, so security is managed by the data sources themselves.
- To ensure that your data in Watson Studio Local is stored securely, you can encrypt your storage partition. If you use Linux Unified Key Setup-on-disk-format (LUKS) for this purpose, then you must enable LUKS and format the partition with XFS before you install Watson Studio Local.
Watson Studio Local supports remote execution to Kerberos-Enabled Spark clusters.