Dell PowerStore 7000T EMC PowerStore Security Configuration Guide - Page 17

SSH authorization, Appliance service scripts, Appliance node Ethernet service port and IPMItool

Get Dell PowerStore 7000T PDF manuals and user guides View all Dell PowerStore 7000T manuals
Add to My Manuals
Save this manual to your list of manuals

Page 17 highlights

SSH authorization Service account authorization is based on the following: • Application isolation - PowerStore software uses container technology that provides application isolation. Appliance service access is provided by the service container, only a set of service scripts and a set of Linux commands are available. The service account does not have the ability to access other containers which serve file system and block I/O to users. • Linux file system permissions - Most Linux tools and utilities that modify system operation in any way are not available for the service user, it requires superuser account privileges. Since the service account does not have such access rights, the service account cannot use Linux tools and utilities to which it does not have execute permissions and cannot edit configuration files that require root access to read or modify, or both. • Access controls - Besides application isolation provided by container technology, the access control list (ACL) mechanism on the appliance uses a list of very specific rules to explicitly grant or deny access to system resources by the service account. These rules specify service account permissions to other areas of the appliance that are not otherwise defined by standard Linux file system permissions. Appliance service scripts A set of problem diagnostic, system configuration, and system recovery scripts are installed on the appliance's software version. These scripts provide an in-depth level of information and a lower level of system control than is available through PowerStore Manager. The PowerStore Service Scripts Guide describes these scripts and their common use cases. Appliance node Ethernet service port and IPMItool Your appliance provides console access over an Ethernet service port that is on each node. This access requires the use of the IPMItool. The IPMItool is a network tool similar to SSH or Telnet that interfaces with each node over an Ethernet connection by using the IPMI protocol. The IPMItool is a Windows utility that negotiates a secure communication channel to access the node console of an appliance. This utility requires physical access to activate the console. The node Ethernet service port interface provides the same functions and features as the service SSH interface (Service LAN interface) and is also subject to the same restrictions. However, users access the interface through an Ethernet port connection rather than an SSH client. This interface is designed for field service personnel who can connect to the appliance without having to disturb your network. A dedicated management console is not necessary. This interface provides a direct point-to-point, non-routable connection. Service personnel can use the Service LAN interface for console output, SSH access to the PowerStore Service Container and PowerStore Manager including the ICW (Initial Configuration Wizard). SSH access to the Service Container through the Service LAN interface is always enabled, and cannot be disabled; however, you manage the service account credential. For a list of service scripts, refer to the PowerStore Service Scripts Guide. NFS secure NFS secure is the use of Kerberos for authenticating users with NFSv3 and NFSv4. Kerberos provides integrity (signing) and privacy (encryption). Integrity and privacy are not required to be enabled, they are NFS export options. Without Kerberos, the server relies entirely on the client to authenticate users: the server trusts the client. With Kerberos this is not the case, the server trusts the Key Distribution Center (KDC). It is the KDC which handles the authentication and manages accounts (principals) and passwords. Moreover, no password in any form is sent on the wire. Without Kerberos, the credential of the user is sent on the wire un-encrypted and thus can easily be spoofed. With Kerberos, the identity (principal) of the user is included in the encrypted Kerberos ticket, which can only be read by the target server and KDC. They are the only ones to know the encryption key. In conjunction with NFS secure, AES128 and AES256 encryption in Kerberos is supported. Along with NFS secure, this also impacts SMB and LDAP. These encryptions are now supported by default by Windows and Linux. These new encryptions are much more secure; however, it is up to the client whether they are used. From that user principal, the server builds the credential of that user by querying the active Unix Directory Service (UDS). Since NIS is not secured, it is not recommended to use it with NFS secure. It is recommended to use Kerberos with LDAP or LDAPS. NFS secure can be configured through PowerStore Manager. Authentication and access 17

  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
  • 19
  • 20
  • 21
  • 22
  • 23
  • 24
  • 25
  • 26
  • 27
  • 28
  • 29
  • 30
  • 31
  • 32
  • 33
  • 34
  • 35
  • 36
  • 37
  • 38
  • 39
  • 40
  • 41
SSH authorization
Service account authorization is based on the following:
•
Application isolation – PowerStore software uses container technology that provides application isolation. Appliance service access is
provided by the service container, only a set of service scripts and a set of Linux commands are available. The service account does
not have the ability to access other containers which serve file system and block I/O to users.
•
Linux file system permissions – Most Linux tools and utilities that modify system operation in any way are not available for the service
user, it requires superuser account privileges. Since the service account does not have such access rights, the service account cannot
use Linux tools and utilities to which it does not have execute permissions and cannot edit configuration files that require root access
to read or modify, or both.
•
Access controls – Besides application isolation provided by container technology, the access control list (ACL) mechanism on the
appliance uses a list of very specific rules to explicitly grant or deny access to system resources by the service account. These rules
specify service account permissions to other areas of the appliance that are not otherwise defined by standard Linux file system
permissions.
Appliance service scripts
A set of problem diagnostic, system configuration, and system recovery scripts are installed on the appliance's software version. These
scripts provide an in-depth level of information and a lower level of system control than is available through PowerStore Manager. The
PowerStore Service Scripts Guide
describes these scripts and their common use cases.
Appliance node Ethernet service port and IPMItool
Your appliance provides console access over an Ethernet service port that is on each node. This access requires the use of the IPMItool.
The IPMItool is a network tool similar to SSH or Telnet that interfaces with each node over an Ethernet connection by using the IPMI
protocol. The IPMItool is a Windows utility that negotiates a secure communication channel to access the node console of an appliance.
This utility requires physical access to activate the console.
The node Ethernet service port interface provides the same functions and features as the service SSH interface (Service LAN interface)
and is also subject to the same restrictions. However, users access the interface through an Ethernet port connection rather than an SSH
client. This interface is designed for field service personnel who can connect to the appliance without having to disturb your network. A
dedicated management console is not necessary.
This interface provides a direct point-to-point, non-routable connection. Service personnel can use the Service LAN interface for console
output, SSH access to the PowerStore Service Container and PowerStore Manager including the ICW (Initial Configuration Wizard). SSH
access to the Service Container through the Service LAN interface is always enabled, and cannot be disabled; however, you manage the
service account credential.
For a list of service scripts, refer to the
PowerStore Service Scripts Guide
.
NFS secure
NFS secure is the use of Kerberos for authenticating users with NFSv3 and NFSv4. Kerberos provides integrity (signing) and privacy
(encryption). Integrity and privacy are not required to be enabled, they are NFS export options.
Without Kerberos, the server relies entirely on the client to authenticate users: the server trusts the client. With Kerberos this is not the
case, the server trusts the Key Distribution Center (KDC). It is the KDC which handles the authentication and manages accounts
(principals) and passwords. Moreover, no password in any form is sent on the wire.
Without Kerberos, the credential of the user is sent on the wire un-encrypted and thus can easily be spoofed. With Kerberos, the identity
(principal) of the user is included in the encrypted Kerberos ticket, which can only be read by the target server and KDC. They are the only
ones to know the encryption key.
In conjunction with NFS secure, AES128 and AES256 encryption in Kerberos is supported. Along with NFS secure, this also impacts SMB
and LDAP. These encryptions are now supported by default by Windows and Linux. These new encryptions are much more secure;
however, it is up to the client whether they are used. From that user principal, the server builds the credential of that user by querying the
active Unix Directory Service (UDS). Since NIS is not secured, it is not recommended to use it with NFS secure. It is recommended to use
Kerberos with LDAP or LDAPS.
NFS secure can be configured through PowerStore Manager.
Authentication and access
17