Skip to content

Fixes #235 #256

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
julian-cable merged 1 commit into from
Jul 29, 2021
Merged

Fixes #235 #256

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
68 changes: 39 additions & 29 deletions en-US/Design.xml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -410,29 +410,28 @@ $ vi myFile.txt

</section>
<section><title>Using Escalated Privileges Correctly</title>

<para>
The term <firstterm>escalated privileges</firstterm> refers to changing to a user whose privileges allow operations that a normal user cannot access.
It also refers to temporarily changing the privileges of the current user to perfom those operations without actually changing user accounts.
</para>
<note>
<para>
This section is aimed primarily at Red&nbsp;Hat Training course material, but the principles and guidelines apply equally in any environment.
</para>
</note>
<para>
The term <firstterm>escalated privileges</firstterm> refers to changing to a user whose privileges allow operations that a normal user cannot access.
It also refers to temporarily changing the privileges of the current user to perfom those operations without actually changing user accounts.
</para>
<note><title>Classroom Exceptions</title>
<para>
Although security is important, it is more important that classroom security does not unnecessarily distract from the immediate topic that is being taught.
</para>
</note>
<section><title>General Recommendations</title>
<note>
<para>
These are recommendations, not rules.
The following are <emphasis>recommendations</emphasis>, not rules.
As in most matters, consistency is important.
Do not swap between different approaches without reason.
Choose which approach works best for your situation and use it consistently.
</para>
</note>
<itemizedlist>
<listitem>
<para>
Expand All @@ -441,7 +440,16 @@ $ vi myFile.txt
</listitem>
<listitem>
<para>
In exercises, use <command>sudo</command> and <command>sudo -i</command> and set it up to work throughout all relevant systems in the classroom.
Use a consistent approach when giving instructions to change users.
For example: "Connect to the cluster node and become the <systemitem>root</systemitem> user."
</para>
<para>
Variations such as "become <systemitem>root</systemitem>" or similar are strongly discouraged.
</para>
</listitem>
<listitem>
<para>
Use <command>sudo</command> and <command>sudo -i</command> and set it up to work throughout all relevant systems.
Do not use <command>su -</command> without good cause.
</para>
</listitem>
Expand All @@ -462,32 +470,34 @@ $ vi myFile.txt
</para>
</listitem>
</itemizedlist>
</section>
<section><title>Exceptions</title>

<note>
<para>
Some courses are specifically designed to teach <command>sudo</command> and its variations, the use of the related files, such as <filename>/etc/sudoers</filename>, and so on.
For these courses, use the required variation for the topic that is being taught.
</para>
<section><title>Ansible Courses</title>
<itemizedlist>
<listitem>
<para>
Ansible courses typically use a <systemitem>devops</systemitem> user with passwordless sudo access (<code>devops ALL=(ALL) NOPASSWD: ALL</code>) on managed nodes to enable the use of <command>become</command> without a <command>become</command> password as <systemitem>root</systemitem> to do anything.
</para>
</listitem>
<listitem>
<para>
As much as possible, leave the system-wide default as <varname>become: false</varname> or <varname>become: no</varname> and if a single task needs privileges, set <varname>become: true</varname> or <varname>become: yes</varname> on that task.
</para>
</listitem>
<listitem>
<para>
If most tasks in a play require escalated privileges, set the entire play to <varname>become: true</varname> or <varname>become: yes</varname> and possibly selectively set individual tasks to <varname>become: false</varname> or <varname>become: no</varname>.
</para>
</listitem>
</itemizedlist>
</section>
</note>
</section>
<section><title>Ansible Courses</title>
<itemizedlist>
<listitem>
<para>
Ansible courses typically use a <systemitem>devops</systemitem> user with passwordless sudo access (<code>devops ALL=(ALL) NOPASSWD: ALL</code>) on managed nodes to enable the use of <command>become</command> without a <command>become</command> password as <systemitem>root</systemitem> to do anything.
</para>
</listitem>
<listitem>
<para>
As much as possible, leave the system-wide default as <varname>become: false</varname> or <varname>become: no</varname> and if a single task needs privileges, set <varname>become: true</varname> or <varname>become: yes</varname> on that task.
</para>
</listitem>
<listitem>
<para>
If most tasks in a play require escalated privileges, set the entire play to <varname>become: true</varname> or <varname>become: yes</varname> and possibly selectively set individual tasks to <varname>become: false</varname> or <varname>become: no</varname>.
</para>
</listitem>
</itemizedlist>
</section>
<!-- </section> -->


</section>
Expand Down