Skip to main content

Cornell University

Marshaling IDs

Use marshaling IDs with your managed server to administer a group of servers as unit. Generally used for scripted operations. 

This article applies to: Managed Servers

On This Page

Marshaling IDs are a mechanism for administering a group of servers as a coordinated unit. Marshaling IDs can be used for:

  • Remote routine administrative tasks.
  • Collecting and consolidating log files or other data.
  • Stopping and/or restarting services.

Controlled and Secure Option for Scripted Operations

Marshaling IDs are generally used for scripted operations. They are facilitated by use of SSH Keys and have special dispensations to bypass password and Secure-ID prompts. They replace rshell commands with a more controlled and secure mechanism. Passwordless SUDO operations may be enabled on Marshaling IDs commands which permit cross system scripts to issue root level commands as required.

Security Units

Each Marshaling ID exists within a unique security unit. Each security unit is set of systems all of which are managed for a single purpose. Security units are a subset of the tiers of security in the Server Farm. Security units allow a group of systems to operate in a concerted fashion. Since Marshaling IDs will have broad latitude to issue root commands, owners need to carefully designate which systems are part of each security unit.

Diagram of Marshaling ID Operations

marshaling-id

Notes:

  • Marshaling ID cannot be used for any other role.
  • Marshaling ID SSH key based on passwordless, exempt from SecurlD.
  • Sudo rights on a per-command basis.
  • SSH keys auto-generated.

Restrictions

The following restrictions will be imposed on marshaling IDs:

  • All participating systems must be members of the same security unit.
  • Will have explicit list of Administrators (hosts that can initiate commands).
  • Will have explicit list of Clients (hosts that can receive and execute commands).
  • SSH Authorized_keys files include a 'from=' clause to inhibit use by non-master hosts.
  • No passwords. Access is SSH-key based, controlled by CFengine.
  • May not be used as a daemon for any public and/or network-facing service.
  • May be granted passwordless SUDO for Specific commands and scripts.
  • A security unit must be wholly contained within one security tier.

Comments?

To share feedback about this page or request support, log in with your NetID

At Cornell we value your privacy. To view
our university's privacy practices, including
information use and third parties, visit University Privacy.