feat: add data sources for querying organization permissions #558
Conversation
Does the PR have any schema changes?Looking good! No breaking changes found. New functions:
Maintainer note: consult the runbook for dealing with any breaking changes. |
There was a problem hiding this comment.
Pull Request Overview
This PR adds four new data sources (invoke functions) to enable querying and auditing organization permissions in Pulumi Cloud for better access management and compliance workflows.
- Adds comprehensive permission auditing capabilities through four new invoke functions
- Enhances API client with methods for querying stacks and permissions
- Generates complete SDK coverage across all supported languages
Reviewed Changes
Copilot reviewed 27 out of 27 changed files in this pull request and generated no comments.
Show a summary per file
| File | Description |
|---|---|
| sdk/python/pulumi_pulumiservice/*.py | Generated Python SDK bindings for the four new invoke functions |
| sdk/nodejs/*.ts | Generated TypeScript SDK bindings and module exports |
| sdk/go/pulumiservice/*.go | Generated Go SDK bindings with proper output types |
| sdk/dotnet/*.cs | Generated .NET SDK bindings with immutable collections |
| provider/pkg/pulumiapi/stack.go | API client methods for stack querying and permission retrieval |
| provider/pkg/pulumiapi/approvals.go | Enhanced UserInfo type with avatar and email fields |
| provider/pkg/provider/provider.go | Implementation of four invoke function handlers |
| provider/cmd/pulumi-resource-pulumiservice/schema.json | Schema definitions for all new invoke functions |
| examples/yaml-permissions-query/* | Comprehensive example demonstrating usage |
| examples/examples_yaml_test.go | Integration test for the new functionality |
| CHANGELOG.md | Documentation of the new features |
Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.
|
@arunkumar611 This should fix your ticket. |
fnune
left a comment
fnune
left a comment
There was a problem hiding this comment.
I would normally approve, but you have enabled auto-merge before getting reviews, so I'm leaving a comments-only review.
I see a lack of testing, I think the integration example examples/yaml-permissions-query/Pulumi.yaml does not exercise the whole API surface.
I also have a minor product concern in that the *Permissions method is an amalgamation of two API calls that may not exactly mean the same as "permissions". I would rather see a cleaner 1-to-1 mapping of the API behavior to the provider functionality.
provider/pkg/provider/provider.go
Outdated
| // invokeFunctionGetStackPermissions implements the getStackPermissions function | ||
| func (k *pulumiserviceProvider) invokeFunctionGetStackPermissions(ctx context.Context, req *pulumirpc.InvokeRequest) (*pulumirpc.InvokeResponse, error) { |
There was a problem hiding this comment.
Why does this one need to go into one? It performs two API calls that do something slightly different, maybe it could map more directly to how our API looks?
Also, I'm not sure how this works, but does fetching collaborators return users that have access to the stack on their own, or do they have access by virtue of being part of a team? In the latter case, is it relevant to know by which team membership they have access?
| variables: | ||
| # Query all teams in the organization | ||
| # Returns: teams[] with kind, name, displayName, description, members[], stacks[], environments[] | ||
| allTeams: | ||
| fn::invoke: | ||
| function: pulumiservice:index:getTeams | ||
| arguments: | ||
| organizationName: ${organizationName} | ||
| return: teams | ||
|
|
||
| # Query all accessible stacks | ||
| # Returns: stacks[] with id, orgName, projectName, stackName, lastUpdate, resourceCount | ||
| allStacks: | ||
| fn::invoke: | ||
| function: pulumiservice:index:getStacks | ||
| arguments: {} | ||
| return: stacks |
There was a problem hiding this comment.
Should we exercise the remainder of the methods as well?
Add four new data sources (invoke functions) to enable querying and auditing
organization permissions in Pulumi Cloud:
- `getTeams`: List all teams in an organization with their members, stack
permissions, and environment permissions
- `getTeamsForUser`: Find which teams a specific user belongs to by searching
their username or GitHub login
- `getStacks`: List all stacks accessible by the authenticated user with
pagination support
- `getStackPermissions`: Query detailed team and user permissions for a
specific stack
- Added `ListUserStacks()` to query accessible stacks via `/api/user/stacks`
- Added `ListStackTeamPermissions()` to query team access via
`/api/stacks/{org}/{project}/{stack}/teams`
- Added `ListStackCollaborators()` to query user access via
`/api/stacks/{org}/{project}/{stack}/collaborators`
- Enhanced existing `UserInfo` type to include `AvatarUrl` and `Email` fields
- Implemented four invoke function handlers in provider.go
- Added comprehensive property conversion helpers
- Added schema definitions for all four invoke functions with detailed
input/output specifications
- Generated SDKs for all supported languages (TypeScript, Python, Go, .NET,
Java)
- All new invoke functions are available across all language SDKs
- Added comprehensive YAML example (`yaml-permissions-query`) demonstrating
all four invoke functions
- Created detailed README with usage examples, use cases, and conversion
instructions
- Updated CHANGELOG.md with feature descriptions
- ✅ Added integration test `TestYamlPermissionsQueryExample` in
`examples/examples_yaml_test.go` - **PASSING**
- ✅ All linting passes with zero issues
- ✅ Provider builds successfully
- ✅ All SDKs generate without errors
- ✅ Integration test validates both `getTeams` and `getStacks` data sources
successfully query live data
These data sources enable several important scenarios:
1. **Audit Organization Access**: Get complete view of teams, members, and
resource access
2. **User Access Review**: Quickly determine what teams and resources a user
has access to
3. **Stack Discovery**: Find all accessible stacks across the organization
4. **Permission Analysis**: Understand exactly who has access to sensitive
stacks
Fixes #509
2 participants
Add four new data sources (invoke functions) to enable querying and auditing organization permissions in Pulumi Cloud:
getTeams: List all teams in an organization with their members, stack permissions, and environment permissionsgetTeamsForUser: Find which teams a specific user belongs to by searching their username or GitHub logingetStacks: List all stacks accessible by the authenticated user with pagination supportgetStackPermissions: Query detailed team and user permissions for a specific stackImplementation Details
API Client Methods
ListUserStacks()to query accessible stacks via/api/user/stacksListStackTeamPermissions()to query team access via/api/stacks/{org}/{project}/{stack}/teamsListStackCollaborators()to query user access via/api/stacks/{org}/{project}/{stack}/collaboratorsUserInfotype to includeAvatarUrlandEmailfieldsProvider Changes
SDK Generation
Documentation
yaml-permissions-query) demonstrating all four invoke functionsTesting
TestYamlPermissionsQueryExampleinexamples/examples_yaml_test.go- PASSINGgetTeamsandgetStacksdata sources successfully query live dataUse Cases
These data sources enable several important scenarios:
Fixes #509