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

Feature Request: Enhance spacelift_user Resource for Granular Policy Management #549

Open
HighwayofLife opened this issue May 7, 2024 · 1 comment

Comments

@HighwayofLife
Copy link

Description:

Currently, the spacelift_user resource in the Spacelift Terraform provider utilizes a repeating policy block to manage user role assignments across spaces. This design presents a major limitation: it requires importing and managing ALL of a user's policy assignments within a single Terraform configuration. Consequently, adding a user to a new space without modifying existing assignments becomes cumbersome and error-prone.

This feature request proposes an enhancement to the spacelift_user resource to enable granular policy management. This would allow adding or removing individual policy assignments without affecting existing ones in different spaces.

Problem:

The current policy block structure forces users to manage all role assignments for a user within a single Terraform configuration. This approach presents several challenges:

  • Increased Complexity: Managing all policy assignments centrally can lead to complex Terraform configurations, especially for users with roles in multiple spaces.
  • Risk of Accidental Modifications: Modifying a user's policy in one space might unintentionally impact their roles in other spaces.
  • Limited Flexibility: Adding a user to a new space without affecting existing assignments becomes difficult and requires workarounds.

Proposed Solution:

Introduce a new resource, such as spacelift_user_policy, dedicated to managing individual policy assignments for users. This resource would take the following attributes:

  • user_id: The ID of the Spacelift user.
  • space_id: The ID of the Spacelift space.
  • role: The role to assign to the user in the specified space.

Example Usage:

resource "spacelift_user" "john_doe" {
  username         = "john.doe"
  invitation_email = "[email protected]"
}

resource "spacelift_user_policy" "john_doe_dev" {
  user_id  = spacelift_user.john_doe.id
  space_id = spacelift_space.dev.id
  role     = "WRITE"
}

resource "spacelift_user_policy" "john_doe_prod" {
  user_id  = spacelift_user.john_doe.id
  space_id = spacelift_space.prod.id
  role     = "READ"
}

Benefits:

  • Simplified Policy Management: Granular control over individual policy assignments without affecting other spaces.
  • Reduced Risk of Errors: Minimize accidental modification of existing policy assignments.
  • Increased Flexibility: Easily add or remove users from spaces without modifying their roles in other spaces.
  • Improved Modularity: Separate user management from policy assignments for better organization and maintainability.

Additional Considerations:

  • The spacelift_user resource could retain the existing policy block for backward compatibility or bulk policy management.
  • Implement import functionality for the new spacelift_user_policy resource to manage existing assignments.
@bushong1
Copy link

We're running into issues from the user policy blocks now. Our big issue is that the underlying structures consider the policy as an ordered list, and any update to add a new block can "change the order of the list." I believe the changes outlined here would solve our issues. One thing to consider though, if policy blocks are retained on the user resource for backwards compatibility, how would the API handle new policies being added from outside of the user resource? There would need to be considerations to avoid reconciling the "drift."

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

No branches or pull requests

2 participants