Use case description

Goal is to pave path for #4313

Currently Framework creates one IAM role, in which all needed statements for all functions are located.

We need a clear understanding which statements, managed policies and eventual principal registrations are required for which function

Current handling of IAM roles

1. Before configuration of all functions is fully processed, IAM role resource is created at mergeIamTemplates function (assuming there's no provider.role set or all functions having role) where:
   • Policy statements needed for logs groups access are added to it
   • Eventual policy statements from provider.iamRoleStatements are added to it
   • Eventual managed policies from provider.iamManagedPolicies are added to it
   • Managed policies needed for VPC configuration are added to it

It is all happening here:

2. In next turn, events are compiled, and then eventual extra statements, polices are added and principals are registered. This is achieved by retrieving IamRoleLambdaExecution resource from serverless.service.provider.compiledCloudFormationTemplate.Resource and adding needed configuration on pre-created object literally, as e.g. it's done here:

   serverless/lib/plugins/aws/package/compile/events/msk/index.js

   Lines 115 to 124 in 4e49473

   	if (cfTemplate.Resources.IamRoleLambdaExecution) {
   	const statement =
   	cfTemplate.Resources.IamRoleLambdaExecution.Properties.Policies[0].PolicyDocument
   	.Statement;
   	if (mskStatement.Resource.length) {
   	statement.push(mskStatement);
   	statement.push(ec2Statement);
   	}
   	}
   	});

Proposed solution

Ideally would be to refactor above into following:

1. At mergeIamTemplates:
   • Create IAM role resources , but with no statements, policies (setup collections, but leave them empty) - we still need to create it here, to not break things for plugins.
   • Create awsProvider.iamConfig and functions[].iamConfig, where each iamConfig is object as follows:

{
  principals: new Set(),
  policyStatements: [],
  managedPolicies: []
};

• Add eventual policy statements from provider.iamRoleStatements to awsProvider.iamConfig.policyStatements
• Add eventual managed policies from provider.iamManagedPolicies to awsProvider.iamConfig.managedPolicies
• If provider.vpc add VPC related polices to awsProvider.iamConfig.managedPolicies

2. In any place where we currently extend IamRoleLambdaExecution directly (look for getRoleLogicalId() and IamRoleLambdaExecution references) Refactor the code, to not extend IAM role resource directly, but instead add related policy statements, managed policies, principals to corresponding function's iamConfig (as those cases will be about specific function event configurations)

3. In lib/plugins/aws/package/compile/functions/index.js:

   • Add related log group policy statements to function's iamConfig.policyStatements (at this point reflect exactly statements as were added at mergeIamTemplates function)
   • If function has vpc configuration add VPC related policies to its iamConfig.managedPolicies

4. Create resolveIamRoles.js in lib/plugins/aws/package/lib which should export a method to be assigned at

   serverless/lib/plugins/aws/package/index.js

   Lines 23 to 31 in 4e49473

   	Object.assign(
   	this,
   	generateCoreTemplate,
   	mergeIamTemplates,
   	generateArtifactDirectoryName,
   	mergeCustomProviderResources,
   	saveServiceState,
   	saveCompiledTemplate
   	);

   invoked at

   serverless/lib/plugins/aws/package/index.js

   Line 69 in 4e49473

   BbPromise.bind(this).then(() =>

   and which should:
   • Register all awProvider.iamConfig.principals and functions[].iamConfig.principals on IamRoleLambdaExecution resource (ensuring no duplicates)
   • Add all awsProvider.iamConfig.managedPolicies and functions[].iamConfig.managedPolicies to IamRoleLambdaExecution resource (ensuring no duplicates)
   • Add all awsProvider.iamConfig.policyStatements and functions[].iamConfig.managedPolicies to IamRoleLambdaExecution resource (ensuring no duplicates)

Testing

This change will likely break a lot of tests, why at the same time we should end with same result CF template.

This signals that again our tests are wrong, and we should not put any effort in updating them in current shape.

Instead, any test file that will host broken tests should be refactored to be based on runServerless (https://github.com/serverless/serverless/tree/master/test#unit-tests), and PR's that refactor each file should be proposed separate (different PR per each test file).

Having those tests migrated to runServerless should keep same tests passing after given refactor is made.