Pre-work Checklist: DevOps-Security-Member: Joss Graf (endlesslupita)

[endlesslupita]

Prerequisite

We are looking forward to having you on our team. Please ensure you have prior experience with the HfLA website team before contributing to our repository.

Overview

As a new member on the HfLA devops-security team, fill in the following fields as you complete each onboarding item.

Special Notes

1. Keep this issue open until you've completed all steps, including learning to provide updates for longer tasks.
2. Normally, handle one issue at a time, but this one is an exception as it teaches how to manage multiple tasks.
3. Work on action items sequentially, but proceed if possible. For example, set up your dev environment without waiting for the weekly meeting.

Action Items

• Before starting to work on the below instructions, make sure to join the #ops Slack Channel. And are a member of devops-security repository.

• Self-assign this issue (gear in right side panel).

• Add this issue to the Project Board under the Projects section (gear in right side panel).

• Attend weekly team meeting, Wednesdays 6-8pm PST.

  • Note: There are no meetings on the 1st-7th of every month.

• Complete the steps in Creating a personal AWS account and Login as root user & setup MFA.

• Read and follow the instructions in Setting up IAM and AWS CLI for:

  • Creating an IAM User
  • Creating an IAM Group
  • Attaching IAM user to IAM Group
  • Providing AdministratorAccess policy to IAM group
  • Log in as the newly created user instead of continuing to log in as the root user (it is not recommended to login with root access).
  • Generating user access keys

• Complete the instructions in AWS Documentation and choose your operating system to install AWS CLI.

• Complete the instruction in AWS Documentation to setup the AWS CLI.

• Read follow the instructions in Creating a backend state.

• Install Terraform locally by following the instructions of the installation guide mentioned in Installing Terraform

• Install Terraform Docs locally by following the instructions of the installation guide mentioned in Installing Terraform docs

• Complete the instructions in Clone the repository

• Submit a new request to create new AWS user account and then self-assign this issue.

• Create a new branch from main by executing the command

  git checkout -b issue-number-add-new-iam-user
  

• Navigate to the aws-user.tf file and add your user information and follow the below template.

  module "iam_user_testiamuser" {
  source = "./modules/aws-users"
  
  user_name = "testiamuser"
  user_tags = {
    "Project"      = "devops-security"
    "Access Level" = "1"
  }
  user_groups = ["read-only-group"]
  }
  

• In your code editor navigate to terraform directory. cd terraform

• Execute the command terraform init to initialize terraform in the directory. Address any failures that arise (if any).

• Execute the command terraform plan this will output a plan replicating the same IAM resources as the devops security account. Address any failures that arise (if any).

• Then execute the command terraform apply this will create all of the resources that are currently managed by Devops Security. All of the resources created here incur zero cost except for the Dynamo DB installation, which should remain in the free tier.
  - [ ] ** If you have cost concerns, Run a Terraform Destroy to take down all of the resources you created (don't worry, you can recreate them just as quickly). **

• Once you have tested your changes, stage them in git with

  • git status command.
  • then git add path/to/file (you can copy from above output for the file path).

• Commit the changes by executing git commit -m "briefly describing the changes".

• Push the changes with git push --set-upstream origin name-of-branch

[endlesslupita]

(Apologies in advance that this suggestion is not in standard format. I haven't learned how to propose documentation edits yet.)

Some questions I considered while drafting these changes: 1. How much should we expect the new member of the team to already know about GitHub or version control in general? vs. spelling everything out in detail 2. How quick is it to troubleshoot if the step is not complete? i.e. which links should we add, and what is the chance that each link will become outdated? 3. Is the pre-work only to help onboard to contribute (infrastructure level) or also to have the new members familiarize themselves with the team's GitHub content and features (knowledge level)?

Suggested edit to Checklist: Split into two list items and revise text.

Original:
Before starting to work on the below instructions, make sure to join the #ops Slack Channel. And are a member of devops-security repository.

New:

[1] Join #ops Slack channel. If you are not a member of the Hack for LA Slack group, request membership via this link: [LINK].

NOTE: Or is the Slack access given during Hack for LA orientation and not being in the Slack group yet means the new member should go back and complete orientation?

[2] Verify that you have permissions in GitHub needed to write to this issue and participate in the DevOps team.

Link from Verify above:

A. Verify that you are a member of the hackforla organization on GitHub. You are a member if the readme.md file you see on the hackforla Overview page says "This is a private page only visible to Hack for LA members." You would have been added during Hack for LA orientation.

B. Verify that you are a member of these teams in the hackforla organization: ops-security, ops-security-write, and ops-write. To view the teams you are in: 1) Click on People in the right column of the hackforla Overview page. 2) Search for your Github user name. 3) On the right of the box with your user info, you should see something like "Public Member [number of] teams." Click on "teams" and a list of teams should appear.

C. Verify that you are a [member?] of the devops-security repository. This is not the same as appearing in the list of contributors (which is only a subset of members).

NOTE: I am not sure that "member" is a role or permission level for a repository. I can't find it in the GitHub documentation. Instead, I see "read, write, maintain, or admin permission levels." They seem to be based on "membership" at the team level. Do we want to say "Verify that you have write permission in the devops-security repository"? Would the easiest test be whether it is possible to check a box in the checklist of the issue and/or whether it is possible to assign oneself to the issue? "Self-assign" is the next task in the checklist.