Chris McKinnel - Implement IAM Permission Boundaries with AWS SSO using Terraform (2022)

Posted by Chris McKinnel - 2 May 2022
8 minute read

Everyone talks about least-privilege in IT, and we all know we should do it. But, the reality is, it's a huge pain to do it properly. It takes longer, it's more expensive, and it causes conflict between teams.

Chris McKinnel - Implement IAM Permission Boundaries with AWS SSO using Terraform (1)

I'm certainly guilty of putting least-privilege into the too-hard-basket, especially on small projects. The problem is, though, if you don't do it from the beginning of the project, or from the foundations of your cloud footprint, then you almost never start doing it later.

If you haven't read The Pragmatic Programmer (published in 1999 - I'm showing my age here, but it's an excellent read), they talk about the Broken Window Theory in relation to writing software in it. It's summarised well below:

Don't leave "broken windows" (bad designs, wrong decisions, or poor code) unrepaired. Fix each one as soon as it is discovered. If there is insufficient time to fix it properly, then board it up. Perhaps you can comment out the offending code, or display a "Not Implemented" message, or substitute dummy data instead. Take some action to prevent further damage and to show that you're on top of the situation.

We've seen clean, functional systems deteriorate pretty quickly once windows start breaking. There are other factors that can contribute to software rot, and we'll touch on some of them elsewhere, but neglect accelerates the rot faster than any other factor.

I think this theory is relevant here - if you don't adopt least-privilege from day-0, then you're on the back-foot and it's much easier to ignore the broken window and continue to grant overly-permissive access going forward. Plus, you'll be more likely to cut other corners and introduce cloud-rot.

Thankfully, though, it's getting easier and easier to provide least-privilege access to cloud resources and services, and there are less and less valid excuses for granting people and applications wide blast-radius access.

One of the scenarios I've struggled with over the years is this: how do you balance giving vendors (for want of a better word, I hate the word "vendor") enough access that they can be autonomous but not grant so much access that they've got the keys to the castle and have a huge blast radius?

And when I say "autonomous", I don't just mean give them the ability to do what they need to do without input from other teams, I also mean it literally. To automate the deployment of cloud resources, especially resources that are deployed in automated pipelines, almost always there is a requirement to deploy IAM roles.

How do you give someone the ability to deploy an IAM role, and grant it permissions, without giving them the ability to just give that IAM role admin access and therefore give themselves admin access?

Read on, dear reader. There is a way.

AWS IAM Permission Boundaries

Permission boundaries have been around for ages, which is quite embarrassing because I haven't been using them. I had a quick Google and it looks like they were introduced in July 2018. Yikes.

Basically, they allow you to attach an IAM policy to an AWS principal that restricts that principal to have no more access than what is defined in the boundary policy, regardless of what is allowed in associated policies.

Chris McKinnel - Implement IAM Permission Boundaries with AWS SSO using Terraform (2)

How do permission boundaries work with AWS SSO?

AWS SSO fully manages our IAM roles for us and they are defined and deployed based on our permission sets, their policies, and which users / groups / accounts they are associated with.

You can't apply permission boundaries directly to permission sets, so on the surface, it appears that they don't play nicely with SSO. I banged my head on this for an hour or two, but then I realised that we don't need to apply permission boundaries directly to the permission sets for them to do their job.

Instead of applying them directly to our permission sets, what we really care about is ensuring that they are applied to new IAM users / roles that are created by our SSO roles. By ensuring that new users / roles have a boundary applied to them, we can be sure that the new users / roles are restricted in what access they can be granted.

So, what we need to do is define our permission sets with inline policies that only allow users / roles to be created that have permission boundaries attached that we've pre-defined.

In the walk-through below, I do this for IAM role creation, but you can and should extend this to user creation.

Least-Privilege

Let's say your customer wants to grant enough access to one of their application development teams (internal or external) that allows them to fully deploy their application using infrastructure as code, including all IAM roles and policies required to run the app.

If you're not using permission boundaries, then you would need to ask the development team for an exact list of roles and permissions they need applied, then assign them yourself. The creation of these roles would need to be decoupled from the deployment of the application, and the application team would be relying on you to get the roles and permissions exactly right or rely on you being available to make iterative changes as permission requirements are uncovered during the deployment.

This sucks, and often causes tension between teams and delays in getting the project deployed (especially if the deployment hasn't been shifted left, and is requested 2 days before the go-live date).

Let's build!

So, let's implement something to see permission boundaries in action.

Before we get started, I implemented this using Terraform on an environment that was using AWS SSO (deployed with Control Tower). If you're not using SSO, your implementation steps will be slightly different - but you should be able to work it out.

Step 1: Create an SSO group manually

Unfortunately, AWS SSO doesn't have a complete API so we can't create our groups using Terraform. We'll have to create our group manually.

We use groups so we don't have to apply permission sets directly to users. It's all good applying permission sets directly to a few users, but it quickly becomes unmanageable when you need to change the policies, or if there is even a modest amount of users that you're applying the permissions to.

Save yourself the trouble and just stamp out the habit of applying permissions directly to users - groups are the way to go.

Navigate to the SSO console and create a group called "PermissionBoundaryTest".

Chris McKinnel - Implement IAM Permission Boundaries with AWS SSO using Terraform (3)

Step 2: Set up Terraform project

providers.tf

provider "aws" { alias = "master_account" region = "ap-southeast-2" profile = var.aws_master_profile}provider "aws" { alias = "non_production_account" region = "ap-southeast-2" profile = var.aws_non_production_profile}

variables.tf

variable "aws_master_profile" { type = string description = "The name of your AWS profile - can be loaded from environment variables"}variable "aws_non_production_profile" { type = string description = "The name of your AWS profile - can be loaded from environment variables"}

terraform.tfvars

aws_master_profile = "master"aws_non_production_profile = "non_production"

We set up multiple providers because we're deploying our permission sets into our master account, which will control the level of permissions that can be assigned to a role in the non-production account, and we're also deploying a policy into the non-production account which we'll use as a permission boundary.

I like to use the AWSCLI configuration files for my AWS credentials and Terraform variables to tell Terraform where to look - I can't claim this is the most efficient way to do things, but it's just how I'm used to doing it.

Step 3: Initialise Terraform project

Before we run terraform init, we need to set up our AWSCLI so it knows which credentials to use. When we set it up, we need to use the same profile names as the ones we've defined in our terraform.tfvars file.

Edit your AWS CLI config files, and add the following:

~/.aws/config

[profile master]region = ap-southeast-2[profile non_production]region = ap-southeast-2

From the SSO login page, click Command line or programmatic access and copy the keys and tokens under Option 2. Paste these into your ~/.aws/credentials file, and change the SSO role name to match your profiles.

Chris McKinnel - Implement IAM Permission Boundaries with AWS SSO using Terraform (4)

~/.aws/credentials

[master]aws_access_key_id=aws_secret_access_key=aws_session_token=[non_production]aws_access_key_id=aws_secret_access_key=aws_session_token=

Now you can run terraform init to get the latest version of the AWS provider installed.

Step 4: Set up some data providers

Before we can define our policies and permission sets, we need to set up some data providers. These will allow our Terraform to talk to our SSO instance, our SSO group and will allow us to reference our AWS account IDs without hardcoding them.

sso.tf

# Data providersdata "aws_ssoadmin_instances" "master" {}data "aws_caller_identity" "non_production" { provider = aws.non_production_account}data "aws_identitystore_group" "permission_boundary_test" { identity_store_id = tolist(data.aws_ssoadmin_instances.master.identity_store_ids)[0] filter { attribute_path = "DisplayName" attribute_value = "PermissionBoundaryTest" }}

We use aws_ssoadmin_instances to get access to our SSO ID, aws_identitystore_group to access our manually created group, and aws_caller_identity to access our account IDs.

Step 5: Define our permission boundary policy

Next we need to define a policy that will act as our permission boundary.

When we reference this policy as a permission boundary for our users or roles later, IAM will ensure that the users and roles will not be able to execute any actions outside the permissions defined in this policy.

sso.tf

# Permission boundary policiesdata "aws_iam_policy_document" "spoke_boundary_policy" { statement { sid = "ServiceBoundaries" actions = [ "s3:createBucket" ] resources = ["arn:aws:s3:::test-bucket-*"] }}resource "aws_iam_policy" "limited_non_production" { provider = aws.non_production_account name = "s3-permission-boundary-policy" description = "S3 Policy for non production" policy = data.aws_iam_policy_document.spoke_boundary_policy.json}

This permission boundary only allows creation of an S3 bucket with the bucket name prefix test-bucket-. When we apply this, it should mean that whatever we apply it to can only create S3 buckets with this prefix.

Step 6: Define permission set policy

Next, we need to define an AWS SSO permission set policy that grants permissions to create S3 bucket, and also to create IAM roles.

The catch is we only allow IAM roles to be created if they have our permission boundary attached to them, meaning the new roles will only ever be allowed to create S3 buckets.

sso.tf

# Spoke permission set policy docdata "aws_iam_policy_document" "spokes" { statement { sid = "ServiceBoundariesS3" actions = [ "s3:createBucket" ] resources = ["arn:aws:s3:::test-bucket-*"] } statement { sid = "ServiceBoundariesIAM" actions = [ "iam:DeleteRole", "iam:DeleteRolePolicy", "iam:DetachRolePolicy", "iam:GetRole", "iam:GetRolePolicy", "iam:ListAttachedRolePolicies", "iam:ListInstanceProfilesForRole", "iam:ListRolePolicies" ] resources = [ "arn:aws:iam::${data.aws_caller_identity.non_production.account_id}:role/test-role-*" ] } statement { sid = "DelegatedRoleBoundary" actions = [ "iam:CreateRole", "iam:AttachRolePolicy", "iam:PutRolePermissionsBoundary", "iam:PutRolePolicy" ] resources = [ "arn:aws:iam::${data.aws_caller_identity.non_production.account_id}:role/test-role-*" ] condition { test = "StringEquals" variable = "iam:PermissionsBoundary" values = [ "arn:aws:iam::${data.aws_caller_identity.non_production.account_id}:policy/s3-permission-boundary-policy" ] } }}

Here, we are defining a permission set that does the following:

  1. Allows the creation of S3 buckets with the test-bucket- prefix
  2. Allows read-only access to IAM roles with the test-role- prefix
  3. Allows deletion of roles with the test-role- prefix
  4. Allows creation of new roles with the test-role- prefix, but only if the s3-permission-boundary-policy is applied as a permission boundary to the role

The key thing here is we're only allowing new roles to be created if they have our pre-defined policy applied as a permission boundary, limiting what the role can do.

Another important thing to note is we aren't using any wildcards in our permission scope or our resource definitions. Using wildcards here can unintentionally increase the scope of the permissions we're granting.

Step 7: Define permission set

Lastly, we need to define a permission set that actually use our policies.

sso.tf

# Non-production permission setresource "aws_ssoadmin_permission_set" "non_production" { provider = aws.master_account name = "S3NonProduction" description = "Permission set to grant S3 access to the non-production account" instance_arn = tolist(data.aws_ssoadmin_instances.master.arns)[0]}resource "aws_ssoadmin_permission_set_inline_policy" "non_production" { provider = aws.master_account inline_policy = data.aws_iam_policy_document.spokes.json instance_arn = aws_ssoadmin_permission_set.non_production.instance_arn permission_set_arn = aws_ssoadmin_permission_set.non_production.arn}resource "aws_ssoadmin_account_assignment" "non_production" { provider = aws.master_account instance_arn = aws_ssoadmin_permission_set.non_production.instance_arn permission_set_arn = aws_ssoadmin_permission_set.non_production.arn principal_id = data.aws_identitystore_group.permission_boundary_test.group_id principal_type = "GROUP" target_id = data.aws_caller_identity.non_production.account_id target_type = "AWS_ACCOUNT"}

Step 8: Deploy everything!

Finally! Let's run a Terraform plan / apply and see where it gets us.

terraform applyTerraform used the selected providers to generate the following execution plan. Resource actions are indicated with the following symbols: + createTerraform will perform the following actions: # aws_iam_policy.limited_non_production will be created + resource "aws_iam_policy" "limited_non_production" { + arn = (known after apply) + description = "S3 Policy for non production" + id = (known after apply) + name = "s3-permission-boundary-policy" + path = "/" + policy = jsonencode( { + Statement = [ + { + Action = "s3:createBucket" + Effect = "Allow" + Resource = "arn:aws:s3:::test-bucket-*" + Sid = "ServiceBoundaries" }, ] + Version = "2012-10-17" } ) + policy_id = (known after apply) + tags_all = (known after apply) } # aws_ssoadmin_account_assignment.non_production will be created + resource "aws_ssoadmin_account_assignment" "non_production" { + id = (known after apply) + instance_arn = "arn:aws:sso:::instance/ssoins-xxxx" + permission_set_arn = (known after apply) + principal_id = "976775fe43-601622db-d510-4589-a13a-xxx" + principal_type = "GROUP" + target_id = "xxxxxxx" + target_type = "AWS_ACCOUNT" } # aws_ssoadmin_permission_set.non_production will be created + resource "aws_ssoadmin_permission_set" "non_production" { + arn = (known after apply) + created_date = (known after apply) + description = "Permission set to grant S3 access to the non-production account" + id = (known after apply) + instance_arn = "arn:aws:sso:::instance/ssoins-8259fdc3de6d1264" + name = "S3NonProduction" + session_duration = "PT1H" + tags_all = (known after apply) } # aws_ssoadmin_permission_set_inline_policy.non_production will be created + resource "aws_ssoadmin_permission_set_inline_policy" "non_production" { + id = (known after apply) + inline_policy = jsonencode( { + Statement = [ + { + Action = "s3:createBucket" + Effect = "Allow" + Resource = "arn:aws:s3:::test-bucket-*" + Sid = "ServiceBoundariesS3" }, + { + Action = [ + "iam:ListRolePolicies", + "iam:ListInstanceProfilesForRole", + "iam:ListAttachedRolePolicies", + "iam:GetRolePolicy", + "iam:GetRole", + "iam:DetachRolePolicy", + "iam:DeleteRolePolicy", + "iam:DeleteRole", ] + Effect = "Allow" + Resource = "arn:aws:iam::xxxxx:role/test-role-*" + Sid = "ServiceBoundariesIAM" }, + { + Action = [ + "iam:PutRolePolicy", + "iam:PutRolePermissionsBoundary", + "iam:CreateRole", + "iam:AttachRolePolicy", ] + Condition = { + StringEquals = { + "iam:PermissionsBoundary" = "arn:aws:iam::xxxxxxxx:policy/s3-permission-boundary-policy" } } + Effect = "Allow" + Resource = "arn:aws:iam::xxxxxxxxxxxxx:role/test-role-*" + Sid = "DelegatedRoleBoundary" }, ] + Version = "2012-10-17" } ) + instance_arn = "arn:aws:sso:::instance/ssoins-xxxx" + permission_set_arn = (known after apply) }Plan: 4 to add, 0 to change, 0 to destroy.Do you want to perform these actions? Terraform will perform the actions described above. Only 'yes' will be accepted to approve. Enter a value: yesaws_ssoadmin_permission_set.non_production: Creating...aws_iam_policy.limited_non_production: Creating...aws_ssoadmin_permission_set.non_production: Creation complete after 6s [id=arn:aws:sso:::permissionSet/ssoins-xxxx/ps-xxx,arn:aws:sso:::instance/ssoins-xxxx]aws_ssoadmin_account_assignment.non_production: Creating...aws_ssoadmin_permission_set_inline_policy.non_production: Creating...aws_iam_policy.limited_non_production: Creation complete after 7s [id=arn:aws:iam::xxxxxxx:policy/s3-permission-boundary-policy]aws_ssoadmin_permission_set_inline_policy.non_production: Creation complete after 5s [id=arn:aws:sso:::permissionSet/ssoins-xxx/ps-xxxx,arn:aws:sso:::instance/ssoins-xxxxxx]aws_ssoadmin_account_assignment.non_production: Creation complete after 5s [id=976775fe43-601622db-d510-4589-a13a-xxx,GROUP,xxxxxx,AWS_ACCOUNT,arn:aws:sso:::permissionSet/ssoins-xxxx/ps-xxxx,arn:aws:sso:::instance/ssoins-xxxx]Apply complete! Resources: 4 added, 0 changed, 0 destroyed.

Nice, now you should see a policy in your spoke account:

Chris McKinnel - Implement IAM Permission Boundaries with AWS SSO using Terraform (5)

And a permission set in your master account:

Chris McKinnel - Implement IAM Permission Boundaries with AWS SSO using Terraform (6)

Step 9: Add your SSO user to the group

Now that everything is deployed, add your user to the SSO group and log out / back into SSO to see the new permission set appear.

Chris McKinnel - Implement IAM Permission Boundaries with AWS SSO using Terraform (7)

Test the thing actually works

OK - now that we've got a permission set deployed, and we can see it on the SSO login page, let's deploy some stuff and test it out.

In a new folder, so the Terraform doesn't conflict, let's define some resources and deploy them using the new permission set by copying the CLI credentials directly into our terminal.

providers.tf

provider "aws" { region = "ap-southeast-2"}

main.tf

data "aws_iam_policy_document" "test" { statement { sid = "test" actions = [ "s3:*" ] resources = ["*"] }}resource "aws_iam_role_policy" "test" { name = "test-policy" role = aws_iam_role.test_role.id policy = data.aws_iam_policy_document.test.json}resource "aws_iam_role" "test_role" { name = "test-role-abc123" assume_role_policy = jsonencode({ Version = "2012-10-17" Statement = [ { Action = "sts:AssumeRole" Effect = "Allow" Sid = "" Principal = { Service = "ec2.amazonaws.com" } } ] })}

There are a few interesting things to note in this Terraform:

  1. We are granting more permissions than we're allowed to! We should be restricted to S3:createBucket, right?
  2. We are granting permissions with a wildcard in Resources - this seems bad
  3. We're not naming the role with our allowed test-role- prefix
  4. We are attempting to deploy the role without a permission boundary, this should be a no-no

Let's deploy it and see what happens (don't forget to terraform init).

terraform applyTerraform used the selected providers to generate the following execution plan. Resource actions are indicated with the following symbols: + createTerraform will perform the following actions: # aws_iam_role.test_role will be created + resource "aws_iam_role" "test_role" { + arn = (known after apply) + assume_role_policy = jsonencode( { + Statement = [ + { + Action = "sts:AssumeRole" + Effect = "Allow" + Principal = { + Service = "ec2.amazonaws.com" } + Sid = "" }, ] + Version = "2012-10-17" } ) + create_date = (known after apply) + force_detach_policies = false + id = (known after apply) + managed_policy_arns = (known after apply) + max_session_duration = 3600 + name = "test_role" + name_prefix = (known after apply) + path = "/" + tags_all = (known after apply) + unique_id = (known after apply) + inline_policy { + name = (known after apply) + policy = (known after apply) } } # aws_iam_role_policy.test will be created + resource "aws_iam_role_policy" "test" { + id = (known after apply) + name = "test-policy" + policy = jsonencode( { + Statement = [ + { + Action = "s3:*" + Effect = "Allow" + Resource = "*" + Sid = "test" }, ] + Version = "2012-10-17" } ) + role = (known after apply) }Plan: 2 to add, 0 to change, 0 to destroy.Do you want to perform these actions? Terraform will perform the actions described above. Only 'yes' will be accepted to approve. Enter a value: yesaws_iam_role.test_role: Creating...╷│ Error: failed creating IAM Role (test_role): AccessDenied: User: arn:aws:sts::xxxxx:assumed-role/AWSReservedSSO_S3NonProduction_xxxxx/chris.mckinnel is not authorized to perform: iam:CreateRole on resource: arn:aws:iam::xxxxxx:role/test_role because no identity-based policy allows the iam:CreateRole action│ status code: 403, request id: xxx-5c59-4d86-ae85-b1bd7763f1fc││ with aws_iam_role.test_role,│ on main.tf line 21, in resource "aws_iam_role" "test_role":│ 21: resource "aws_iam_role" "test_role" {│╵

You'll notice that the error message is kind of vague - you're not allowed to do that because "reasons".

Let's try to fix our role name prefix, and add the permission boundary.

main.tf

resource "aws_iam_role" "test_role" { name = "test-role-abc123" permissions_boundary = "arn:aws:iam::xxxxxx:policy/s3-permission-boundary-policy" assume_role_policy = jsonencode({ Version = "2012-10-17" Statement = [ { Action = "sts:AssumeRole" Effect = "Allow" Sid = "" Principal = { Service = "ec2.amazonaws.com" } } ] })}

And redeploy:

terraform applyTerraform used the selected providers to generate the following execution plan. Resource actions are indicated with the following symbols: + createTerraform will perform the following actions: # aws_iam_role.test_role will be created + resource "aws_iam_role" "test_role" { + arn = (known after apply) + assume_role_policy = jsonencode( { + Statement = [ + { + Action = "sts:AssumeRole" + Effect = "Allow" + Principal = { + Service = "ec2.amazonaws.com" } + Sid = "" }, ] + Version = "2012-10-17" } ) + create_date = (known after apply) + force_detach_policies = false + id = (known after apply) + managed_policy_arns = (known after apply) + max_session_duration = 3600 + name = "test-role-abc123" + name_prefix = (known after apply) + path = "/" + permissions_boundary = "arn:aws:iam::xxxxxxx:policy/s3-permission-boundary-policy" + tags_all = (known after apply) + unique_id = (known after apply) + inline_policy { + name = (known after apply) + policy = (known after apply) } } # aws_iam_role_policy.test will be created + resource "aws_iam_role_policy" "test" { + id = (known after apply) + name = "test-policy" + policy = jsonencode( { + Statement = [ + { + Action = "s3:*" + Effect = "Allow" + Resource = "*" + Sid = "test" }, ] + Version = "2012-10-17" } ) + role = (known after apply) }Plan: 2 to add, 0 to change, 0 to destroy.Do you want to perform these actions? Terraform will perform the actions described above. Only 'yes' will be accepted to approve. Enter a value: yesaws_iam_role.test_role: Creating...aws_iam_role.test_role: Creation complete after 8s [id=test-role-abc123]aws_iam_role_policy.test: Creating...aws_iam_role_policy.test: Creation complete after 0s [id=test-role-abc123:test-policy]Apply complete! Resources: 2 added, 0 changed, 0 destroyed.

It worked! Uh oh, that's not good, right? Isn't it supposed to stop us from deploying roles that have more permissions than our permission boundary?

That's what I thought, too. But after giving it a little more thought, it did make sense to me that it would let you create permissive roles as long as the permission boundary was attached.

IAM already has the logic defined to figure out if you're allowed to perform actions at runtime, so why try and reproduce the same logic to role / policy creation time? The result is still the same, our permission boundary should trump what is in our role policy.

It does mean that if our permission boundary gets removed at any point, though, our role will have more permissions than it should. Not sure how I feel about that.

Anyway, don't take my word for it, though, let's use the IAM Policy Simulator to figure out if we've got more access than we should.

Simulate the policies

First up, make sure you're logged into the account where you deployed your role, then find the role in the IAM console. There will be a simulate button you can click that launches the Policy Simulator.

Chris McKinnel - Implement IAM Permission Boundaries with AWS SSO using Terraform (8)

In here we can select our role (and notice that it shows the policy attached to it, and the permission boundary as well), and then select the things we think we should be able to do on the right-hand side and then hit simulate.

Here, we select the s3:CreateBucket permission and hit simulate.

Chris McKinnel - Implement IAM Permission Boundaries with AWS SSO using Terraform (9)

OK, so we can see that we're not allowed to create an S3 bucket. Hmm, but didn't our policy say that we should be able to? Yes, but we did specify that the bucket we create must have a test-bucket- prefix in our permission boundary.

Even though our role policy says we should be allowed to create a bucket with any name, our permission boundary is stopping us. Great! That means it's working as expected.

So, we need to tell the policy simulator what the bucket name is that we intend to create and hit simulate:

Chris McKinnel - Implement IAM Permission Boundaries with AWS SSO using Terraform (10)

Nice, now we can see that our role is allowed to create an S3 bucket with the prefix we defined in our policy.

Let's try deleting the bucket with the allowed prefix. Our policy says we should be allowed to (because of the * in the allow block and the * in the resources block).

Chris McKinnel - Implement IAM Permission Boundaries with AWS SSO using Terraform (11)

Ah ha, excellent, we're not allowed to delete because our permission boundary is doing what it should. Remember, even though your role policy says you're allowed to, it's trumped by the permission boundary policy!

Play around with other permissions in the simulator and you'll see that our new role is restricted to only creating buckets, nothing else.

Wrapping up

If you're not currently adhering to least-privilege best practice, start repairing those broken windows today. Tighten up your vendors' access levels by implementing permission boundaries.

Hopefully, this post has helped you figure out how you can implement them with AWS SSO, because it's not obvious at first glance.

Top Articles

Latest Posts

Article information

Author: Nathanael Baumbach

Last Updated: 11/02/2022

Views: 6116

Rating: 4.4 / 5 (75 voted)

Reviews: 82% of readers found this page helpful

Author information

Name: Nathanael Baumbach

Birthday: 1998-12-02

Address: Apt. 829 751 Glover View, West Orlando, IN 22436

Phone: +901025288581

Job: Internal IT Coordinator

Hobby: Gunsmithing, Motor sports, Flying, Skiing, Hooping, Lego building, Ice skating

Introduction: My name is Nathanael Baumbach, I am a fantastic, nice, victorious, brave, healthy, cute, glorious person who loves writing and wants to share my knowledge and understanding with you.