Update the SMCE docs

Author: GeorgianaElena

docs/howto/archive-homedir.md

@@ -0,0 +1,24 @@
+- aws access to the cluster
+
+
+Create a bucket in S3:
+aws s3 s3://jmte-prod-homedirs-archive --region us-west-2
+aws s3 ls
+
+
+Create a role with no permissions:
+aws iam get-role --role-name homedirs-archive-access
+
+
+Create a policy that can write into that bucket, and attach it to the role we just created:
+
+aws iam put-role-policy --role-name homedirs-archive-access --policy-name HomedirsArchiveAccess_policy --policy-document '{"Version":"2012-10-17","Statement":[{"Effect":"Allow","Action":"s3:*","Resource":["arn:aws:s3:::jmte-prod-homedirs-archive","arn:aws:s3:::jmte-prod-homedirs-archive/*"]}]}'
+
+
+python3 archive-home-dirs.py \
+    --archive-name="archive-$(date +'%Y-%m-%d')" \
+    --basedir=/home/jovyan/allusers/ \
+    --bucket-name=jmte-prod-homedirs-archive \
+    --object-prefix="archives/" \
+    --usernames-file=to_archive.txt \
+    --temp-path=/home/jovyan/archive-staging/

docs/howto/regenerate-smce-creds.md

@@ -1,4 +1,4 @@
-# Regenerate credentials for NASA SMDC accounts
+# Regenerate credentials for NASA SMDE accounts
 
 This document describes how we regenerate credentials for _users_ and the `deployer` when they expire in NASA SMDC accounts.
 
@@ -55,19 +55,3 @@ This document describes how we regenerate credentials for _users_ and the `deplo
    ```
 
    You can then open a Pull Request and merge it.
-
-(nasa-smce:regenerate-user-password)=
-## Regenerate a password for a user in a NASA SMDC account
-
-The AWS accounts associated with NASA's [Science Managed Cloud Environment](https://smce.nasa.gov)
-have a 60 day password expiry policy. If someone on the team misses this
-deadline, we can actually reset passwords for each other!
-
-1. Someone in the team with access logs into the AWS console of the appropriate project
-2. Follow [AWS's user guide on resetting passwords](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_passwords_admin-change-user.html#id_credentials_passwords_admin-change-user_console)
-   for whoever's 60 day window has elpased
-3. In addition, a `AccountDisabled` IAM Group will be automatically added to the
-   user whenever their credentials expire, and this will show up as a "cannot
-   change password" error when the user logs in next. So the user should also be
-   removed from this group. You can do so from under the "Groups" tab in the
-   AWS console when looking at the details of this user.

docs/hub-deployment-guide/new-cluster/smce.md

@@ -2,9 +2,20 @@
 
 Cloud resources for NASA's [Science Managed Cloud Environment](https://smce.nasa.gov/) (SMCE) is managed via an AWS organization and access via a SSO service.
 
+Once the steps below are done, steps for the regular [AWS Cluster Setup](new-cluster:new-cluster) can proceed,
+until completion of [provisioning credentials for CI/CD](new-cluster:terraform:cluster-credentials).
+
+## Getting an account
+
+1. The community representative will get in touch with SMCE to setup a Science Cloud account for each 2i2c member.
+2. This account will have to be added by the community to their AWS SSO.
+3. We will then be able to login each of the SMCE AWS accounts we have access to.
+
 ## Signing into the AWS SSO
 
-To sign into the AWS SSO, you need to go to the [SMCE portal](https://aws.sciencecloud.nasa.gov/). Your Science Cloud identity is tied to your 2i2c.org email address and managed via Microsoft online. Here are the steps to follow:
+### Via the UI
+
+To sign into the AWS SSO, you need to go to the [SMDC portal](https://aws.sciencecloud.nasa.gov/). Your Science Cloud identity is tied to your 2i2c.org email address and managed via Microsoft online. Here are the steps to follow:
 
 1. Visit the following link: [http://aws.sciencecloud.nasa.gov/](http://aws.sciencecloud.nasa.gov/)
 1. Login using your 2i2c.org email address
@@ -18,78 +29,45 @@ Select the permission level you need to perform your work, and you will be direc
 
 You can also copy and paste the access keys you require into your terminal to use the AWS CLI.
 
-## Getting an account
-
-This is very much the same as getting access to any other AWS account where billing is handled for us by someone else.
-
-1. The community representative will get in touch with SMCE to either provision a new
-   AWS account, or grant us full access to one that already exists.
-
-2. Once the community representative has access, they will create an
-   IAM account for *one* 2i2c engineer in this account, and make sure
-   they are a part of the `SMCE-ProjectAdmins` group.  This gives us
-   full access to the AWS account, and we can add other engineers here.
-
-3. This engineer should log in with the credentials provided by the community representative, and set up [Multi Factor Authentication](https://aws.amazon.com/iam/features/mfa/), using [this dashboard link](https://us-east-1.console.aws.amazon.com/iamv2/home?region=us-west-2#/security_credentials/mfa). This is required in all SMCE environments. You need to log out of the AWS console and back in after setting up MFA to see your full permissions.
+### Via the terminal
+Follow the instructions at [](cloud-access:aws-sso:terminal) to get access into the cluster.
 
-4. This engineer should now create user accounts for all other 2i2c engineers, and make sure they are all part of the `SMCE-ProjectAdmins` group.
+The rest of the process should be the same.
 
-Once this is done, steps for the regular [AWS Cluster Setup](new-cluster:new-cluster) can proceed,
-until completion of [provisioning credentials for CI/CD](new-cluster:terraform:cluster-credentials).
+## Get eksctl access into the cluster for everyone using an AWS SSO user
+
+1. Login into the hub via the terminal following the steps linked above.
+2. Assume the Project-Admin role for the cluster you want to get access to.
+2. Get the exact role name assumed by the SSO user as follows:
+   ```bash
+   role=$(aws sts get-caller-identity --query "Arn" --output text | grep --only-matching -E "AWS[^\/]+")
+   ```
+3. From the role name, determine the ARN
+   ```bash
+   arn=$(aws iam get-role --role-name "$role" --output text --query Role.Arn)
+   ```
+4. Create an access entry for this ARN
+   ```bash
+   aws eks create-access-entry --cluster-name "$CLUSTER_NAME" --principal-arn "$arn" --region "$REGION"
+   ```
+5. Associate that access entry with the AmazonEKSClusterAdminPolicy
+   ```bash
+   aws eks associate-access-policy \
+   --cluster-name "$CLUSTER_NAME" \
+   --region "$REGION" \
+   --principal-arn "$arn" \
+   --policy-arn arn:aws:eks::aws:cluster-access-policy/AmazonEKSClusterAdminPolicy \
+   --access-scope type=cluster
+   ```
 
 ## `hub-continuous-deployer` user
 
-By default, we don't have permissions to create additional IAM users. This is a problem for our continuous deployer user `hub-continuous-deployer`. SMCE / SMDC is able to grant us exemptions though.
-
-### SMDE
+By default, we don't have permissions to create additional IAM users. This is a problem for our continuous deployer user `hub-continuous-deployer`. SMCE is able to grant us exemptions though.
 
 Right now, SMDE has to manually create the account named `hub-continuous-deployer`. This
 has to be requested through their internal systems (that are opaque to us). Once created,
 we can import that into our terraform with `terraform import -var-file=projects/${project}.tfvars aws_iam_user.continuous_deployer hub-continuous-deployer`.
 
-The rest of the process should be the same.
-
-### SMCE
-
-The process for SMCE is a bit different. We can create the user account, but there's a
-MFA requirement that must be exempted.
-
-At the completion of [provisioning credentials for CI/CD](new-cluster:terraform:cluster-credentials),
-we will have a IAM user named `hub-continuous-deployer` provisioned. This is what we use to
-deploy from GitHub actions, but also to deploy from our local machines. The MFA requirement
-needs to be exempted for this user before we can continue and actually deploy our hubs.
-
-The engineer needs to reach out to the community representative at this point, and ask
-for the MFA exemption. `hub-continuous-deployer` has a very narrow scope of permissions - only
-`eks:DescribeCluster` on the specific cluster we deployed. The community representative will
-have to reach out via their own internal processes to grant this exemption. This has
-always been granted so far - VEDA, GHG - and should not be a problem to get granted again.
-We have also received assurances that this process would be expedited to the extent possible.
-
-You can verify that this MFA exemption has been processed by looking at the list of groups
-the `hub-continuous-deployer` user belongs to. It should *not* contain the user `SMCE-UserRestrictions`.
-
-Once this exemption has been processed, you can continue as usual with deployment of the hub.
-
-## Preparing for routine regeneration of the `hub-continuous-deployer` access credentials
-
-The `hub-continuous-deployer` has an access key and secret associated with it, this is how it
-authenticates with AWS to perform actions. SMCE accounts have a 60 day password/access key
-regeneration policy and so we need to prepare to regularly regenerate this access key.
-See [](nasa-smce:regenerate-deployer-creds) for how to reset the credentials.
-
-```{warning}
-We only receive **5 days notice** that a password/access key will expire via email!
-
-Also it is unclear who receives this email: all engineers or just the engineer who
-setup the cluster?
-```
-
-```{note}
-See [](nasa-smce:regenerate-user-password) for how to reset an expired password for
-a _user_, e.g., a member of the engineering team.
-```
-
 ## Cost allocation tags
 
 [Cost allocation tags](howto:cost-monitoring:activate-tags) have been enabled at the AWS organization level for SMCE. Therefore we do not need to enable them with our terraform configuration, i.e. the variable `enable_cost_allocation_tags` is set to `false` by default, so we do not need to include this in the `projects/<project>.tfvars` file.