Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Manage users on Datadog with Terraform #318

Merged
merged 21 commits into from
Jun 6, 2024

Conversation

jdno
Copy link
Member

@jdno jdno commented Jul 13, 2023

A Terraform module has been created similar to the existing modules to manage team access to Datadog.

@@ -0,0 +1,24 @@
# This file is maintained automatically by "terraform init".
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Shouldn't you ignore this file, though?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No, we want to make sure that we're all using the same versions. terraform init fetches the versions that are locked in .terraform.lock.hcl, and only upgrades them when explicitly called with terraform init -upgrade.

// Configuration for Terraform itself.

terraform {
required_version = "~> 1"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Isn't it a better idea to pin it to something before the BUSL license was introduced? e.g. ~> 1.5

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

AFAIK the license change doesn't impact us as end-users of Terraform, since we're not embedding Terraform or its source code in a commercial product that we're selling. At least that's how I understand their FAQ.

required_providers {
datadog = {
source = "datadog/datadog"
version = "3.24.1"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

And perhaps pinning this version to include all the patch ones: ~> 3.24

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There's a broader discussion coming up once in a while about our infrastructure-as-code tooling and its issues and limitations. One of the things that we're struggling with is keeping our modules and dependencies up-to-date. It's not too bad here, but for other modules it's quite a lot of work to update something, because then every service that depends on that module needs to be manually redeployed.

I think it's fine to leave it as-is for now, since we really need to solve this in an holistic way for the whole repository.

Comment on lines +13 to +20
backend "s3" {
bucket = "rust-terraform"
key = "simpleinfra/team-members-datadog.tfstate"
region = "us-west-1"
dynamodb_table = "terraform-state-lock"
encrypt = true
}
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wander, doesn't simpleinfra use Terragrunt? Wouldn't it be better to use the DRY it offers?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Terragrunt is really handy for things that have multiple environments like production and staging. The team access will only ever have a single instance, so we haven't bothered moving it over to Terragrunt yet. And since the other rest of the team access is managed with Terraform as well, I didn't want to make this a one-off configuration in a different place.

A Terraform module has been created similar to the existing modules to
manage team access to Datadog.
Instead of relying on teams to tag incoming resources and to use them
in restriction queries, we are using teams and the `service` or `app`
tag to control access to resources. The teams have been removed again,
and a more limited role for contributors and a "marker role" for the
crates.io team have been created.
Some board members are interested in some of our metrics as part of
their work in the different committees of the board. A very limited
read-only role has been created to grant them access to our
organization.
The marker role did not work as expected, since contributors had
unrestricted access to logs. The `Contributor` role has been removed
for this reason, and its permissions are now explicitly granted to
members of the `crates-io` role.
The list of users has been split into multiple files, each representing
a single team. This makes it much easier to manage the access for
individual teams. An unsolved problem is that users can be members of
multiple teams, which is not modelled yet.
Teams are a relatively new feature on Datadog that makes it easier to
share resources with a specific subset of users. For example, dashboards
can be owned by teams and surfaced more prominently to members of that
team.
When a user is part of multiple teams, they might have multiple roles.
These are now all assigned to the user, and Datadog will determine the
user's permissions based on that list.
@jdno jdno merged commit 828f8c1 into rust-lang:master Jun 6, 2024
3 checks passed
@jdno jdno deleted the datadog-team-access branch June 6, 2024 12:38
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants