Introduction

The Linux Server Fabric from zibernetics is part of the ziNet Security Fabric. The Linux Server Fabric allows for centralized management to the operational environment based on user identity and authorization rules. Consider the following diagram for an IT infrastructure. In this diagram there are multiple subnets that contain servers which must be managed, including fail over in a different availability zone. A typical approach for accessing these servers would be to manage pushing ssh public keys to individual servers via manual or automated processes. There are multiple problems with this approach, one of which is keeping track of which users are still in the employ of the organization. Another problem with this is that once a key is on the server a user will be able to access the server even though they no longer may have authorization, i.e. they moved out of the department that manages servers.

By being build on top of the Identity and Access Fabric (IAM Fabric), the Linux Server Fabric can centralize a user's identity and authorization rule in a central repository and; therefore, can control which users can access the operational environment on the fly. The advantages of this approach is that all features of the IAM Fabric can be leveraged to control access. Features like disabled account status can now be implemented to prevent unauthorized access to systems. Identity Groups can be used to model different concepts of the operational architecture.

Linux Server Architecture

Architecturally speaking, Linux Server is the component of the ziNet Security Fabric responsible for authentication and authorization to the operational environment. The architectural components of Linux Server Fabric are:

Layers - A layer ties together groups of Users and Hosts at a high level.
Groups - A group can be a group of Users or other Groups.
Hosts - A Host is a server entity
User - An entity representing a User

Layer

A Layer is the logical grouping providing access to a set of users to a set of hosts. A Layer may contain users, groups of users, hosts, groups of hosts or hosts. In the case of users (or groups of users), they will be granted access to any server in the authorization chain for the Layer. In the case of host (or groups of hosts), these are the total set of servers that can be accessed in the Layer.

Looking at the diagram below you can see how a security fabric can be overlaid in the operational environment to model your specific access requirements. In this example we have created the following:

A Virtual Private Cloud (VPC) Layer - This layer provides access to all Users in the group called "SecurityAdmins." Therefore, those users have access to ALL servers in the entire operational environment.
Production Public Layer / Production Private Layer - This layer provides access to all Users in the DevOps and ITOps groups.
Operations Private Layer - This layer provides access to all Users in the ITOps group.
Engineering Private Layer - This layer provides access to all Users in the DevOps, Developers, and Contractors groups.
Database Private Layer - This layer provides access to all Users in the ITOps and DBAs groups.

The layer specification would look like this:

Layer Specification

################################################
#
#   Production Public Layer
#
################################################
dn: cn=prod-pub-101000,ou=Layers,dc=ops,dc=ziNet,dc=com
objectClass: top
objectClass: groupOfUniqueNames
cn: prod-pub-101000
uniqueMember: cn=grp_devops,ou=Groups,dc=ops,dc=ziNet,dc=com
uniqueMember: cn=grp_itops,ou=Groups,dc=ops,dc=ziNet,dc=com
uniqueMember: cn=prod-pub-101000-server,ou=Hosts,dc=ops,dc=ziNet,dc=com
ou: Layer
################################################
#
#   Production Private Layer
#
################################################
dn: cn=ops-prv-101002,ou=Layers,dc=ops,dc=ziNet,dc=com
objectClass: top
objectClass: groupOfUniqueNames
cn: ops-prv-101002
uniqueMember: cn=grp_itops,ou=Groups,dc=ops,dc=ziNet,dc=com
uniqueMember: cn=ops-prv-101002-server,ou=Hosts,dc=ops,dc=ziNet,dc=com
uniqueMember: cn=dba-prv-101002-server,ou=Hosts,dc=ops,dc=ziNet,dc=com
ou: Layer
################################################
#
#   Engineering Private Layer
#
################################################
dn: cn=eng-prv-101004,ou=Layers,dc=ops,dc=ziNet,dc=com
objectClass: top
objectClass: groupOfUniqueNames
cn: eng-prv-101004
uniqueMember: cn=grp_devops,ou=Groups,dc=ops,dc=ziNet,dc=com
uniqueMember: cn=grp_contractors,ou=Groups,dc=ops,dc=ziNet,dc=com
uniqueMember: cn=grp_developers,ou=Groups,dc=ops,dc=ziNet,dc=com
uniqueMember: cn=eng-prv-101004-server,ou=Hosts,dc=ops,dc=ziNet,dc=com
uniqueMember: cn=dba-prv-101004-server,ou=Hosts,dc=ops,dc=ziNet,dc=com
ou: Layer
################################################
#
#   Database Private Layer
#
################################################
dn: cn=database-priv-101000,ou=Layers,dc=ops,dc=ziNet,dc=com
objectClass: top
objectClass: groupOfUniqueNames
cn: database-priv-101000
uniqueMember: cn=grp_itops,ou=Groups,dc=ops,dc=ziNet,dc=com
uniqueMember: cn=dba-prv-101002-server,ou=Hosts,dc=ops,dc=ziNet,dc=com
uniqueMember: cn=dba-prv-101004-server,ou=Hosts,dc=ops,dc=ziNet,dc=com
ou: Layer
################################################
#
#   Production Public Layer
#
################################################
dn: cn=zinet-vpc-1010,ou=Layers,dc=ops,dc=ziNet,dc=com
objectClass: top
objectClass: groupOfUniqueNames
cn: cibo-zinet-vpc-1010
uniqueMember: cn=Linux Server_admins,ou=Groups,dc=ops,dc=ziNet,dc=com
uniqueMember: cn=prod-pub-101000,ou=Layers,dc=ops,dc=ziNet,dc=com
uniqueMember: cn=ops-prv-101002,ou=Layers,dc=ops,dc=ziNet,dc=com
uniqueMember: cn=eng-prv-101004,ou=Layers,dc=ops,dc=ziNet,dc=com
uniqueMember: cn=database-priv-101000,ou=Layers,dc=ops,dc=ziNet,dc=com
ou: Layer

Group

The Group is the preferred method of managing User access, as opposed to adding Users directly to Hosts or Layer entities. This allows for easier maintenance of operations. The only notable point for creating groups is that they must be both posixGroup and groupOfUniqueNames. As a posixGroup, the gidNumber must be unique.

Group Specification

dn: cn=grp_devops,ou=Groups,dc=ops,dc=ziNet,dc=com
objectClass: top
objectClass: groupOfUniqueNames
objectClass: posixGroup
cn: grp_devops
ou: Group
gidNumber: $((localPosixGroupIdx++))

Hosts

A Host is a logical representation of a server. A host need not represent a single server; in fact, as a best practice it should represent a set of servers. From a deployment perspective, the host ID (the CN attribute) is what one or more servers would be configured. This gives all servers configured with this ID to have the same access rules. In the example below, the following Host entities are configured.

prod-pub-101000-server - This is the ID that hosts in the Production Public and Production Private Layer use. This associates the NAT Server, VPN Server, Production Proxies, Production Servers, and Production Databases servers to this layer.
ops-prv-101002-server - This is the ID that hosts in the Operations Private Layer use. This associates IT Ops Services, Directory Services, and DevOps Services servers to this layer.
eng-prv-101004-server - This is the ID that hosts in the Engineering Private Layer use. This associates the Engineering Servers and Engineering Databases servers to this layer.
db-prv-virt-server - This is the ID that hosts in the Database Private Layer use. This associates the Production DBs and Engineering DBs servers to this layer.

Linux Server Setup

Linux Server is easy to setup. The related configuration can be found here.

Linux Server Runtime

Linux Server has two runtime components SSH integration and LDAP schema. You can learn more about them here.