Tenant Onboarding Customization

[chandanadatta9]

Hi,

I have quick question on Tenant Onboarding Flow customization on the Control Plane Side.
Currently Control plane creates an API Gateway with POST /tenants endpoint forwarding to tenant management lambda function to create tenants and as part of this the lambda function first puts the request onto DynamoDB and then creates a control plane event which will then be picked up by CoreUtilsAppPlane.

Now is there a way we can customize after receiving request on POST /tenants endpoint and after storing on DynamoDB before it sends a controlplaneevent, would like to have custom logic run and based on that we would like to then put a message on Event Bus

Is this possible?

[suhussai]

Hi @chandanadatta9 , are you to provide more details as to what "custom logic" you'd like to run?

Based on what you wrote above, there are a couple ways this can be supported:

1. Create a rule that listens to the message emitted by the lambda running behind the POST /tenants endpoint. Then, have that rule trigger your custom logic to determine whether another message should be emitted that your CoreUtilsAppPlane will listen to. Basically, here we are adding a middle layer between the /tenants lambda function and CoreUtilsAppPlane.
2. Another option might be include that custom logic into your CoreUtilsAppPlane. For example, if that custom logic is meant to check a condition that indicates whether or not resources should be provisioned, this could be included as part of the resource provisioning process.
3. Another option is forking the repo, and manually updating the POST /tenants lambda to do what you indicated above. The downsides is that it will make it potentially more difficult for you to pull in upstream changes, so I wouldn't do this personally.

Those are the options I can think of. Based on the purpose of the custom logic and what you are trying to do, I would go with either option 1 or 2.

If you're able to share, we might be able to recommend one option over another or provide another suggestion.

Hope that helps!

[chandanadatta9]

Hi @suhussai,

Basically the reason for our custom logic is that, we are planning to manage AWS Account Creation. For some of the tenants we will be creating them an AWS Account specific to them.

So basically we upon a tenant signup request we will have our custom logic run and we will trigger our AWS Account creation process. We would want this to be on the Control Plane side of the SaaS Platform. Then once an AWS Account is created we will out another message on the Event Bus to provision the actual application infrastructure.

Coming to the 3 recommended approaches, we are also leaning towards option 1. But there are a couple of things,

• Basically the POST /tenants endpoint is putting on onboardingRequest event onto the eventBridge to which the provisioning ScriptJob StepFunction is configured as the Target. Now even if we create a rule that listens to the onboardingRequest request and triggers our custom lambda, it will also trigger the provisioning scriptJob StepFunction. I mean we could have some kind of attributes that our Provisioning ScriptJob checks to see of they are present and only if they are present Provisioning will run if not only custom logic to create an account runs. wanted to see if there is any other better way.
• Other thing is we would like to save back some information(e.g. account ID) in the tenant details DynamoDB, but since it is not exposed as an output from ControlPlane unlike API Gateway and EventManager, it is hard for us to get the ARN of the DynamoDB and create an IAM Role using that ARN to putItems onto that DynamoDB. Let us know if there is any other way to store data into the tenant Details dynamoDB.

[suhussai]

Thanks for the detailed reply!

Regarding the account creation, is there a reason why you are wanting to handle that in the control plane? To me, that is part of the tenant provisioning process, and so should be the responsibility for the provisioning process. The control plane should just put a message indicating that a new tenant should be provisioned and the provisioning process should handle the rest (including creating a new account when necessary).

The other thing I would recommend is having a central AWS account that's responsible for deploying into your different AWS accounts instead of replicating the provisioning process in every account that you need to deploy into.

Pushing out the account creation to the provisioning process should solve your first point. As for your 2nd point, you can use this https://constructs.dev/packages/@cdklabs/sbt-aws/v/0.5.7/api/ProvisioningScriptJob?lang=typescript#property.environmentVariablesToOutgoingEvent to indicate what you'd like to extract from your provisioning process (such as the account id) and that information should make its way into the tenant details table.

Hope that makes sense!

[suhussai]

Here is a simple example that shows how you can use it:

sbt-aws/src/core-app-plane/integ.default.ts

Lines 90 to 97 in 2716e5e

	environmentVariablesToOutgoingEvent: [
	'tenantS3Bucket',
	'tenantConfig',
	'tenantStatus',
	'prices', // added so we don't lose it for targets beyond provisioning (ex. billing)
	'tenantName', // added so we don't lose it for targets beyond provisioning (ex. billing)
	'email', // added so we don't lose it for targets beyond provisioning (ex. billing)
	],

Basically, just export the variables in the script job and SBT will take that and use it to update that tenant.

[chandanadatta9]

Thanks for the detailed reply!

Regarding the account creation, is there a reason why you are wanting to handle that in the control plane? To me, that is part of the tenant provisioning process, and so should be the responsibility for the provisioning process. The control plane should just put a message indicating that a new tenant should be provisioned and the provisioning process should handle the rest (including creating a new account when necessary).

The other thing I would recommend is having a central AWS account that's responsible for deploying into your different AWS accounts instead of replicating the provisioning process in every account that you need to deploy into.

Pushing out the account creation to the provisioning process should solve your first point. As for your 2nd point, you can use this https://constructs.dev/packages/@cdklabs/sbt-aws/v/0.5.7/api/ProvisioningScriptJob?lang=typescript#property.environmentVariablesToOutgoingEvent to indicate what you'd like to extract from your provisioning process (such as the account id) and that information should make its way into the tenant details table.

Hope that makes sense!

@suhussai, thank you very much for your response. The reason why we thought of having Account Provisioning as part of the control plane is that since Account Creation is tied closely to Security, Governance, and Organization Structure, though it would make sense to for Control Plane to Manage it. That way App Plane Core Utils can handle tenant specific application deployment and operations after the foundational aspect of account creation is complete. Still Account Creation will be part of tenant onboarding but it is orchestrated by Control Plane as part of the governance process and then it will be handed over to the Core Utils to install app components for the tenant.

• Yes, we have a Central account where our account provisioning is handled. So when there is a new tenant being onboarded, our plan is to have a request to be made from SBT to the central account(call to API Gateway in the Account provisioning central account) to create an account. Once the account is created Central account will place an event onto the SBT Event Bridge which will then be handled to continue to the tenant onboarding Core Utils.

• For environmentVariablesToOutgoingEvent as you said, if we were handling the account creation in the App Plane Core Utils this would have been helpful. Since we are still thinking to handle account creation part in the Control Plane we are thinking to make a PUT /tenants API call once an AWS Account is created to update tenant information with AWS Account.
  Still we are think as per you recommendation of moving the Account creation to App Plane, but then we would have to write the provisioning Script to make the AWS Account Creation API creation first (which usually takes 10min-15min to finish), then check for the completion of account creation and save the information and then trigger the App Plane to install tenant specific Application Components in the new AWS Account.

[suhussai]

Just following up here to see what you ended up doing. Curious to see how you implemented the solution. Any updates you can share?