-
Notifications
You must be signed in to change notification settings - Fork 77
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
Conversation
@@ -0,0 +1,24 @@ | |||
# This file is maintained automatically by "terraform init". |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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" |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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" |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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.
backend "s3" { | ||
bucket = "rust-terraform" | ||
key = "simpleinfra/team-members-datadog.tfstate" | ||
region = "us-west-1" | ||
dynamodb_table = "terraform-state-lock" | ||
encrypt = true | ||
} | ||
} |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
d53025a
to
4a29baf
Compare
Saved views on Datadog are globally shared across an organization, so we want to limit who can create them to ensure a high signal-to-noise ratio. We can consider loosening this restriction as we gain more experience with the platform.
A Terraform module has been created similar to the existing modules to manage team access to Datadog.