kalleeh / gurum-api Goto Github PK

https://docs.aws.amazon.com/serverlessrepo/latest/devguide/serverlessrepo-publishing-applications.html

• Evaluate steps needed to package to sar
• Decide between 1 or 2 packages

Run the below script from the ./deploy script.
pip install aws-xray-sdk --target lambda_layers/aws-xray-sdk/python

Update the readme once complete.

We need to look at setting up a linting git hook when a commit is made.
This will help us catch errors earlier.

Maybe something along the lines of this:
https://ljvmiranda921.github.io/notebook/2018/06/21/precommits-using-black-and-flake8/

Right now CloudWatch Log Groups doesn't get tags inherited from their CloudFormation stags.
CW Logs doesn't support tag based authorization either.

Currently the Cognito IAM Roles inherited by users through Cognito Groups can read from any log group but when this is added we could easily tag the log groups and then modify the IAM Role that cognito users assume to add tag based authorization to their respective log group similar to CFN templates etc.

https://docs.aws.amazon.com/IAM/latest/UserGuide/access_tags.html

{
    "Effect": "Allow",
    "Action": [
        "logs:FilterLogEvents"
    ],
    "Resource": "arn:aws:logs:[region]:[account-id]:log-group:*",
    "Condition": {
        "StringEquals": {"ec2:ResourceTag/gureume-groups": "team1"}
    }
}

Running tests on PR, block if failing.
Automatic versioning.
Create GitHub release when merged to master

Consider updating the template_generator function to generate the templates through CDK rather than picking static templates from an S3-bucket.

This could enable easier mapping of applications to services, dynamically generating least privilege IAM policies etc.

See what missing automation steps we can add with the recent extended CloudFormation support for Cognito.

https://aws.amazon.com/about-aws/whats-new/2019/10/amazon-cognito-increases-cloudformation-support/

Documentation refers to "pip install x-ray dependencies" which can install the x-ray dependencies for python 2 version. This breaks api. Change documentation to pip3 install and see if we can verify the python x-ray package version to be 3 or raise an error otherwise.

We need to clarify the steps around creating the initial users and groups and IAM role mappings through cognito federated identities for first setup users.
We don't want to build a user management system in the API since this should use the default Cognito API's but we should provide configuration steps.

Something like;

1. Create Cognito user.
2. Create Cognito group for each Platform Tenant.
3. Create IAM Role with correct CloudWatch Logs Read-permissions (right log groups). Add the right trust permissions on the IAM role.

{
      "Effect": "Allow",
      "Principal": {
        "Federated": "cognito-identity.amazonaws.com"
      },
      "Action": "sts:AssumeRoleWithWebIdentity",
      "Condition": {
        "StringEquals": {
          "cognito-identity.amazonaws.com:aud": "eu-west-1:b3df4e00-5aea-4e69-8b60-85ec38731d17"
        },
        "ForAnyValue:StringLike": {
          "cognito-identity.amazonaws.com:amr": "authenticated"
        }
      }
    }

4. Map Cognito group login to the IAM role created in step 3.
5. Go into Cognito Federated Identities and go to Authentication providers, Cognito. Under "authenticated role selection" select "choose role from token" and "use Authenticated role".

Since the original S3 Bucket is created manually outside the lifecycle of either the Gureume Platform or API stack currently there is no way to properly update the S3 Bucket policy.
This is a manual step that requires the copy pasting of IAM Role ARN for Create and Update Lambda functions to get GetObject-access to the bucket holding the app/pipeline/service templates.

We need to implement a way to fetch already existing parameters and configure a parameter file as part of the pipeline rather than using CodePipelines Parameter Override function since it just sets the parameters specifically configured, and doesn't reuse existing ones.

Add more dynamic support in the API for dynamic parameters and product types. Today they are somewhat hardcoded which makes it hard to extend applications, pipelines and services to new types with totally different parameters.

Add API endpoint for initialize an app. Creating a pipeline to parse service.yaml and orchestrate the other API calls accordingly.

Backend for this
kalleeh/gurum-cli#10