[mattdjenkinson]

Registers feedback with Milo IAM, and closes a gap where the website could see hidden posts. Closes #10.

Stacked on #28 (security reports), which is on #27, #26, #25, #23, #22 and #16.

The hidden-post gap

The design lets any authenticated principal read posts, including datum.net's service account, which reads in the platform context. Until now the platform context alone was enough to see hidden posts, so the website would have shown them.

Hidden posts are now visible only to callers allowed get on a posts/hidden virtual subresource, checked through the apiserver's delegated authorizer (a SubjectAccessReview to Milo, cached by the apiserver). Staff, feedback-sync and feedback-controller have it; users and the website don't. Milo enforces subresource permissions separately because ENABLE_SUBRESOURCE_AUTHORIZATION is on in staging and production. Without an authorizer, as in tests and local development, the old platform-context rule applies.

Milo IAM (config/milo/iam)

• ProtectedResources: one per kind, with subresources: status, posts/hidden, submissions/review, submissions/attachment, submissions/to-security-report and securityreports/attachment. User-facing kinds take User as a parent, so a user's own permissions apply in their user context. FeedbackSource has no parent, so it's platform-only.

• Roles:

  Role	Holds
  user	browse and search, vote, follow, upload, send submissions and reports, read your own
  public-reader	for datum.net: visible posts, releases, changelog, PostQuery, acknowledgements
  viewer	staff read access, including hidden posts, votes and subscriptions; no submissions or reports
  reviewer	viewer, plus submissions, reviews, to-security-report, hiding posts
  editor / admin	FeedbackSource management; admin also inherits reviewer
  security-team	security reports, status and attachments; nothing else grants securityreports

Service identities (config/milo/rbac)

Milo authorizes with RBAC,Webhook, so the service's own components get Kubernetes RBAC in Milo as client-certificate users, scoped to their own work rather than system:masters:

• system:feedback-sync@feedback.miloapis.com:
  • reads FeedbackSources and writes their status;
  • creates, updates and deletes posts, releases and changelog entries, including their status;
  • gets posts/hidden;
  • reads submissions and writes their status.
• system:feedback-controller@feedback.miloapis.com:
  • reads posts, releases, changelog entries, submissions, votes, subscriptions, security reports and FeedbackSources;
  • writes post and submission status;
  • gets posts/hidden;
  • creates postqueries.
• system:feedback-apiserver@feedback.miloapis.com:
  • creates resourcesearchqueries;
  • lists organizationmemberships and useridentities;
  • plus system:auth-delegator and the authentication reader for delegated auth.

identity.Default now uses these usernames, replacing the guessed service account names from #23.

Discovery and bindings

• Discovery: user-facing resources appear in the platform and user contexts, and feedbacksources only in the platform context.
• config/milo/bindings (optional): the feedback-security-team Group with security-team bindings, and reviewer bindings for staff-users, one per kind. Who holds which role is a deployment decision, so this component isn't included by default.

Context rules in the apiserver

Milo enforces these first. The apiserver now checks them as well:

• staff can list votes and subscriptions but can't update or delete them;
• FeedbackSource refuses non-platform contexts on every verb.

The rest of the API-contexts table was already enforced by #4 to #9.

For #13

• Patch iam-user-self-manage to add feedback.miloapis.com-user to inheritedRoles, keeping activity's audit-log querier, since a strategic merge replaces the list.
• Include config/milo and decide on bindings/.
• Bind public-reader to datum.net's identity.
• Issue client certificates with the three common names above, without system:masters.

Testing

• TestMiloConfig checks that:

  • every kind has a ProtectedResource;
  • every role permission and RBAC rule names a declared resource and verb;
  • inherited roles exist;
  • discovery lists every resource;
  • bindings name real roles and kinds;
  • the RBAC subjects match the identity defaults;
  • no role but security-team and user touches securityreports.

  Adding posts.watch and securityreports.list to the viewer role makes it fail on both.

• Unit tests: hidden posts with an authorizer (the website gets NotFound on get and list; staff and sync read and update); staff are read-only on votes and subscriptions; FeedbackSource refuses the user context on every verb.

• Kind cluster, with the real config/milo/rbac applied and sync and the controller running as their certificate users:

  • sync created posts and the controller couldn't;
  • staff hid a post, after which a read-only website stand-in got NotFound and didn't see it in the list, while staff and sync still read and updated it;
  • the controller wrote delivery status;
  • sync was refused security reports;
  • staff couldn't delete Alice's vote;
  • Alice couldn't list FeedbackSources;
  • PostQuery left out the hidden post.