Page tree

Vorschläge:

  • keine Verwendung des Begriffs Lightweight Account mehr, führt nur zur Verwirrung,
    besser sinngemäß von minimal gefordertem Set an Attributen sprechen
  • Umbenennung des Account Typen Functional in der neuen Registry 2.0 in Shared,
    es besteht eine zu große Gefahr der permanenten Verwechslung zwischen Functional und Service
  • Einführung eines weiteren Account Typen für Maschinen oder Experimente Kontrollen,
    die Abbildung über Blueprints halte ich für ungeeignet


Account Typen
Registry 1

Account Typen
Registry 2

Account
shared

Private
Data

Account
never expires

Password
never expires

Login
von außerhalb (ssh, vpn)

Zugang  Intranet Internet

Compromised Account
will be blocked without discussion

Compromised Account
will be blocked only after discussion

Approval required (D4)

Intended Purposes

Examples

Primary
noallowednonoallowedyesyesnono

Primarynoallowednonoallowedyesyesnonoalways first account for a person
Personal
noallowednonoallowedyesyesnono

Personalnoallowednonoallowedyesyesnonoadmin accounts
Functional
yesnoallowedallowednot allowed???no

Functionalyesnonononot allowedyesyesnonotemporary guests, students, temporary services, e.g. conferences, group accounts

Sharedyesnoallowed
(default yes)
allowed
(default no)
not allowedyesyesnonoshared data, email addresses, lab operation, e.g. measurements, automation solutions

Serviceyesnoyesyesnot allowednonoyesyesaccelerator and experiment controls,
services for important infrastructure

zur Diskussion:

  • Approval für Service Accounts für ganze Namespaces wie MCA möglich
  • Es gibt sehr viele Gruppen Accounts, häufig auch für kurzzeitige Gäste (< 1 Woche) eingesetzt, hier scheint der Migrationspfad nicht klar
    • zu welchem Account Typen sollen diese gehören? Sie benötigen ANE (das Ablaufdatum ist das des NS selber) aber keinesfalls PNE
    • kann man Accounts auch an die Namespace Supervisoren bzw. den Namespace binden, d.h. nicht an Einzelpersonen? Würde m.E. Sinn machen
  • Was bedeutet, dass ein Account geblockt werden kann? Werden zukünftig auch Automaten aktiv, die blockieren? Wie sieht das dahinterliegende Konzept aus?
  • Wie kann man zuverlässig verhindern, dass irgendein Account der Maschinenkontrollen ohne Rückfrage und einem ok aus dem M-Bereich geblockt werden kann?
    Aus meiner Sicht muss man evtl. ganze Namespaces davon ausnehmen können, ein Flag (mittels Blueprint) reicht m.E. nicht aus, das scheint mir im Betrieb zu unsicher, wird leicht übersehen,
    insbesondere, wenn es manuell vergeben werden muss, sollte man dafür nicht einen extra Account Typen spendieren?
  • Warum soll es account never expires und cannot be disabled für alle Account Typen geben, worin liegt da der Sinn? Das lädt doch zu Mißbrauch geradezu ein.
  • Kann man einen Account gleichzeitig mehr als einem Blueprint zuordnen?
  • No labels