Added the infra SOPs ported to asciidoc.

modules/sysadmin_guide/pages/aws-access.adoc

@@ -0,0 +1,152 @@
+= Amazon Web Services Access
+
+AWS includes a highly granular set of access policies, which can be
+combined into roles and groups. Ipsilon is used to translate between IAM
+policy groupings and groups in the Fedora Account System (FAS). Tags and
+namespaces are used to keep roles resources seperate.
+
+== Contact Information
+
+Owner::
+  Fedora Infrastructure Team
+Contact::
+  #fedora-admin
+Persons::
+  nirik, pfrields
+Location::
+  ?
+Servers::
+  N/A
+Purpose::
+  Provide AWS resource access to contributors via FAS group membership.
+
+== Accessing the AWS Console
+
+To access the AWS Console via Ipsilon authentication, use
+https://id.fedoraproject.org/saml2/SSO/Redirect?SPIdentifier=urn:amazon:webservices&RelayState=https://console.aws.amazon.com[this
+SAML link].
+
+You must be in the
+https://admin.fedoraproject.org/accounts/group/view/aws-iam[aws-iam FAS
+group] (or another group with access) to perform this action.
+
+=== Adding a role to AWS IAM
+
+Sign into AWS via the URL above, and visit
+https://console.aws.amazon.com/iam/home[Identity and Access Management
+(IAM)] in the Security, Identity and Compliance tools.
+
+Choose Roles to view current roles. Confirm there is not already a role
+matching the one you need. If not, create a new role as follows:
+
+[arabic]
+. Select _Create role_.
+. Select _SAML 2.0 federation_.
+. Choose the SAML provider _id.fedoraproject.org_, which should already
+be populated as a choice from previous use.
+. Select the attribute _SAML:aud_. For value, enter
+_https://signin.aws.amazon.com/saml_. Do not add a condition. Proceed to
+the next step.
+. Assign the appropriate policies from the pre-existing IAM policies.
+It's unlikely you'll have to create your own, which is outside the scope
+of this SOP. Then proceed to the next step.
+. Set the role name and description. It is recommended you use the
+_same_ role name as the FAS group for clarity. Fill in a longer
+description to clarify the purpose of the role. Then choose _Create
+role_.
+
+Note or copy the Role ARN (Amazon Resource Name) for the new role.
+You'll need this in the mapping below.
+
+=== Adding a group to FAS
+
+When finished, login to FAS and create a group to correspond to the new
+role. Use the prefix _aws-_ to denote new AWS roles in FAS. This makes
+them easier to locate in a search.
+
+It may be appropriate to set group ownership for _aws-_ groups to an
+Infrastructure team principal, and then add others as users or sponsors.
+This is especially worth considering for groups that have modify (full)
+access to an AWS resource.
+
+=== Adding an IAM role mapping in Ipsilon
+
+Add the new role mapping for FAS group to Role ARN in the ansible git
+repo, under _roles/ipsilon/files/infofas.py_. Current mappings look like
+this:
+
+....
+aws_groups = {
+    'aws-master': 'arn:aws:iam::125523088429:role/aws-master',
+    'aws-iam': 'arn:aws:iam::125523088429:role/aws-iam',
+    'aws-billing': 'arn:aws:iam::125523088429:role/aws-billing',
+    'aws-atomic': 'arn:aws:iam::125523088429:role/aws-atomic',
+    'aws-s3-readonly': 'arn:aws:iam::125523088429:role/aws-s3-readonly'
+}
+....
+
+Add your mapping to the dictionary as shown. Start a new build/rollout
+of the ipsilon project in openshift to make the changes live.
+
+=== User accounts
+
+If you only need to use the web interface to aws, a role (and associated
+policy) should be all you need, however, if you need cli access, you
+will need a user and a token. Users should be named the same as the role
+they are associated with.
+
+=== Role and User policies
+
+Each Role (and user if there is a user needed for the role) should have
+the same policy attached to it. Policies are named
+'fedora-$rolename-$service' ie, 'fedora-infra-ec2'. A copy of polices is
+available in the ansible repo under files/aws/iam/policies. These are in
+json form.
+
+Policies are setup such that roles/users can do most things with a
+resource if it's untagged. If it's tagged it MUST be tagged with their
+group: FedoraGroup / $groupname. If it's tagged with another group name,
+they cannot do anything with or to that resource. (Aside from seeing it
+exists).
+
+If there's a permssion you need, please file a ticket and it will be
+evaluated.
+
+Users MUST keep tokens private and secure. YOU are responsible for all
+use of tokens issued to you from Fedora Infrastructure. Report any
+compromised or possibly public tokens as soon as you are aware.
+
+Users MUST tag resources with their FedoraGroup tag within one day, or
+the resource may be removed.
+
+=== ec2
+
+users/roles with ec2 permissions should always tag their instances with
+their FedoraGroup as soon as possible. Untagged resources can be
+terminated at any time.
+
+=== s3
+
+users/roles with s3 permissions will be given specific bucket(s) that
+they can manage/use. Care should be taken to make sure nothing in them
+is public that should not be.
+
+=== cloudfront
+
+Please file a ticket if you need cloudfront and infrastructure will do
+any needed setup if approved.
+
+== Regions
+
+Users/groups are encouraged to use regions 'near' them or wherever makes
+the most sense. If you are trying to create ec2 instances you will need
+infrastructure to create a vpc in the region with network, etc. File a
+ticket for such requests.
+
+== Other Notes
+
+AWS resource access that is not read-only should be treated with care.
+In some cases, Amazon or other entities may absorb AWS costs, so changes
+in usage can cause issues if not controlled or monitored. If you have
+doubts about access, consult the Fedora Project Leader or Fedora
+Engineering Manager.