Knowledge Base

Summary of policy

1. User accounts for humans must be domain accounts.
2. Groups must be domain groups.
3. Service accounts must be local accounts and have a unique uid within the entire environment.
4. Passwordless login is allowed within guidelines.
5. The name of a user or group must not have any spaces.
6. Access to servers is granted to only groups, not individual users.
7. Service accounts may be granted direct ssh access within guidelines.

Annotated policy

1. User accounts for humans must be domain accounts.
2. Groups must be domain groups.
   1. Centralized user and group administration is a corporate standard and is necessary for our scale of operations.
   2. The domain to use, unless under special circumstances, is Active Directory domain PROD1.
3. Service accounts must be local accounts.
   1. Service accounts are used by applications and processes that should run independently of any individual users, and should not depend on domain resolution.
   2. UIDs for local accounts must be unique within the entire environment. For example, the service account "abcapp" is UID 9950 and no other local account can use that UID anywhere. These UIDs are managed by the Linux Engineering team in file control5:/etc/ansible/uid_gid.
4. Passwordless login is allowed within guidelines.
   1. Kerberos (GSSAPI) authentication between hosts joined to the same domain is enabled by our server configuration standard.
   2. Ssh key authentication for users and service accounts is allowed and users may manage their own keys.
5. The name of a user or group must not have any spaces.
   1. While spaces can technically be used, the complexity of supporting spaces in user and group names reduces the effectiveness of automation.
6. Access to servers is granted to only groups, not individual users.
   1. To comply with RBAC guidelines, access must be provided to only groups, even if this means adding a group in the same domain as a single user to provide access to that user. A recommended group name is username_ssh, e.g., mysql_ssh.
7. Service accounts may be granted direct ssh access within guidelines.
   1. Most access to service accounts is through sudo su $SERVICEACCOUNT.
   2. Applications and processes with a valid business justification for direct ssh access will be granted direct access after approval . Abuse of a service account direct ssh access includes a human logging in to a service account over direct ssh to an interactive shell. Any such abuse may cause the service account direct ssh access to be revoked.