...
Note that since the development Slack is on a free plan, messages posted in it effectively have a 90-day retention period. Therefore, only use it for testing minerva Minerva and leave conversations to the main Slack.
...
The Development Google Calendar is the Google Calendar that the development Minerva reads events from and writes events ontointeracts with. You can view it from here.
In order to get edit access to the calendar, which is essential for testing Minerva’s calendar functionality, send a Slack DM to one of the primary contributors to the project, or to the Software Lead.Note to those inviting new users:
Instructions for onboarders
New users should be invited and given the “Make changes to events” permission on the Google Calendar once added. If you do not have “Make changes and manage sharing” permissions for the Google Calendar, and are therefore unable give them edit access, you can use the Development Google Account to give yourself the permissions to do so.
Access to the AWS Console
...
For making changes to Minerva’s infrastructure and viewing logs you will need access to the AWS console. This console can be accessed here.
Accessing the AWS console requires the creation of a user account to login with. To have a user account created for yourself, send a Slack DM to one of the primary contributors to the project, or to the Software Lead.
Instructions for onboarders
Overview
Three IAM user groups currently exist for our AWS account:
AWSAdmin - Only to be given to Software Lead + highly trusted developers. Gives the
AdministratorAccesspermission policy to users, which gives you access over everything (except for billing). This should also be the only role that can create new user accounts.AWSUser - Gives full access to services such as Lambda, EventBridge, API Gateway, S3, and Cloudformation. To be only given to trusted users who actually need direct write access to AWS infrastructure, which is likely no one as changes can be made through the CDK stack in a much more transparent way.
AWSUser_ReadOnly - The default group to assign to new users. Gives read-only access to all the necessary services.
Note that the non-admin groups have the DenyKMS policy, which prevents them from viewing the environment variables that are used by all lambda functions on the account (and therefore the secrets that they use). This is necessary as AWS Secrets Manager does not have a free tier. When creating new user groups, ensure that this policy is applied to it unless it is an admin-like role.
Creating new AWS user accounts
Navigate to the “create user” page in IAM
Enter a user name for the account. Make it something straightforward, like the individual’s WatIAM ID (e.g.
cwijesek)Check the “Provide user access to the AWS Management Console” box, check the “I want to create an IAM user” radio button (we’re not using AWS Identity Center…for now), and click “next”.
Select the User group that you want the user to be a part of. In almost all cases, this is just the
AWSUser_ReadOnlygroup. Click “next”.Verify that all the configurations are correct and if so, click on the “Create user” button.
Send the listed user name and console password to the individual that you are creating the account for. Note that the password provided is temporary and on the user’s first login they will be prompted to change it.