Rudder

• Si on affiche les policy serveurs dans les moteurs de recherches, ils vont être dans les groupes (ou alors, les groupes ne correspondront pas aux recherches)
• Si on a des PS dans des groupes, on risque d'avoir des CR qui leur sont appliqués, alors qu'on ne veut en général pas
• Comment definir une PI qui peut s'appliquer ou non à un PS ?

Nicolas CHARLES a écrit:

Ca pose pleins de problèmes :

• Si on affiche les policy serveurs dans les moteurs de recherches, ils vont être dans les groupes (ou alors, les groupes ne correspondront pas aux recherches)
• Si on a des PS dans des groupes, on risque d'avoir des CR qui leur sont appliqués, alors qu'on ne veut en général pas

Oui, c'est entre autres le but de cette question.

"On ne veut en général pas" --> sauf qu'une politique de sécurité qui s'applique à tout un SI, sauf au serveur qui gère la politique c'est un peu comme un président de la république qui outrepasserait les lois qu'il a créées :)

J'ai d'ores et déjà le cas aujourd'hui : ma politique "SSH" met tous mes serveurs SSH sur le port 5190 sans connexions par mot de passe autorisés, sauf que celui du serveur Rudder est resté en 22 avec ces connexions autorisées...

La question sous-jacente est pourquoi on a peur d'appliquer des CR sur le serveur Rudder ? De peur de casser son fonctionnement ? Si oui, pourquoi on ne mettrait pas une autre instance Cfengine (non configurable via Rudder) qui ne sert qu'à configurer le serveur Rudder (en gros celle qu'on a aujourd'hui) plus l'agent standard à côté ? Ou quelque chose du genre...

• Comment definir une PI qui peut s'appliquer ou non à un PS ?

Je pense pas qu'il faille. C'est tout de même à l'utilisateur de savoir ce qu'il installe où - rien ne l'empêche aujourd'hui d'installer autre chose manuellement sur le serveur Rudder, et ainsi de risquer de casser son fonctionnement.