Define Security Attributes permissions model

Summary

This issue tracks the definition of the permissions model for the Security Attributes feature, based on discussions in the parent epic.

Background

From the discussion thread starting at &18010 (comment 2571374168), we need to define and implement the permissions approach for Security Attributes.

Requirements

New Permission Required

• Create a new permission that provides CRUD capabilities for security labels/categories
• Permission name: admin_security_attributes (or similar)

Permission Assignment Strategy

• Default Security Role: Include the new permission in the default security role so users with this role have access by default
• Custom Roles: Allow the permission to be assigned to custom roles for users with other default roles (e.g., specific developers)
• Flexibility: This approach gives customers sufficient flexibility to control access to security attributes

View Permissions

• No restrictions on viewing security labels if user has view access for the associated project
• Users should be able to see security attributes wherever they're displayed (project metadata, security inventory, etc.) if they can view the project

Permission Scope

• Permissions should be evaluated at the root group level where security attributes are configured
• Users need appropriate permissions on the root group to:
  • Edit the set of available labels for the group
  • Apply labels to projects within the group

Specific Permission Requirements

Users with the new permission should be able to:

• Create new security attribute categories
• Read existing security attribute categories and labels
• Update security attribute categories and labels
• Delete security attribute categories and labels (where appropriate)
• Apply security labels to projects within the group hierarchy

Acceptance Criteria

• Define the new admin_security_attributes permission (or finalize naming)
• Specify permission assignment to default security role
• Ensure custom role compatibility
• Implement view permissions approach (no restrictions for project viewers)
• Validate root group permission scope
• Create permission checks in relevant controllers/services
• Update relevant documentation
• Add permission to GraphQL schema where needed

Technical Considerations

Permission Evaluation Points

• Group-level security configuration pages
• Project-level security configuration pages
• Security inventory pages
• Any API endpoints for security attributes

Integration with Existing Permissions

• Should work alongside existing read_security_configuration permission
• Consider interaction with project-level permissions vs group-level permissions

Related Issues

Parent Epic: &18010

Additional Context

This permissions model balances security and flexibility by:

1. Providing sensible defaults through the security role
2. Allowing customization through custom roles
3. Not restricting visibility unnecessarily
4. Maintaining appropriate access control for modification operations

The discussion participants (@smeadzinger, @mfluharty, @or-gal) agreed on this approach as providing the right balance of security and usability.