Configuring a default IAM identity

You can configure a default IAM identity for each project. The default IAM identity of a project will be used by all jobs defined in that project, when they are launched without an explicit IAM identity. It remains possible to override the default IAM identity by explicitly setting the appropriate attribute on the instantiated Airflow operators.

You can change the default IAM identity through the project settings page in the UI, or via the CLI:

conveyor project update --default-identity="A new identity"

Templating the default IAM identity

Having a static identity as the default is not that useful, which is why the default identity can be templated.

We recommend that your project uses a different IAM identity for every environment to make sure development and production are properly segregated via the rights attached to that IAM identity.

AWS

For more information on how to set up AWS identity see our article on Using AWS Roles.

For the default identity we recommend using something like this.

my-role-for-{{ .Env }}

We show the result for a couple of environments:

environment	result
production	my-role-for-production
development	my-role-for-development

This requires that you include the environment name in the AWS roles you prepare for your projects.

You can also only include part of the environment name in the role name. This allows you to trivially reuse a role for multiple environments that share the same access level. This pattern is particularly useful when you want to for example share the same role across multiple individual development environments. If they for example prefix their environment name with dev-, they can be allowed to use that role.

For example:

my-role-for-{{slice .Env 0 3}}

environment	result
production	my-role-for-pro
development	my-role-for-dev
dev-your-user	my-role-for-dev

Azure

On Azure, authentication is typically done through Service Principals or Managed Identities. In these cases, the IAM identity required for Conveyor jobs is the Client ID of these resources.

Please refer to our article Azure Service principals or Managed identities on how to set up the Azure service principals.

Matching the right ID to the right environment is a bit more involved on Azure, but it can be achieved by using a template that follows a pattern like this one:

{{if eq .Env "production"}}PRODUCTION_ID{{end}}{{if eq .Env "development"}}DEVELOPMENT_ID{{end}}

This will result in the following:

environment	result
production	PRODUCTION_ID
development	DEVELOPMENT_ID
another-env