User story #5627: Readonly API or otherwise restrictable API Accounts - Rudder - Issue Tracker

Custom queries

8.1 beta
Bugs triage
My TR
Need technical review
Open bugs (all)
Open bugs (UI - UX)
Open issues 8.0
Open UX defects (all)
Opened by users

Actions

Copy link

User story #5627

closed

Readonly API or otherwise restrictable API Accounts

Added by Florian Heigl over 9 years ago. Updated almost 6 years ago.

Status:

Released

Priority:

N/A

Assignee:

François ARMAND

Category:

API

Target version:

4.3.0~beta1

Pull Request:

https://github.com/Normation/rudder/p...

UX impact:

Suggestion strength:

User visibility:

Effort required:

Name check:

Fix check:

Regression:

Description

Hi,

currently it is possible to create different API Accounts for different tasks.
For outside interaction (other applications pulling data from rudder) the API works but not in all cases the accessing application should be permitted to do any changes in rudder.

Some way for this would be having accounts that are restricted to i.e. readonly accesses.

Subtasks 4 (0 open — 4 closed)

User story #11946: Interface to manage API account authorization	Released	Vincent MEMBRÉ	Actions
User story #11947: Add an interface to manage api account expiration date	Rejected		Actions
Bug #12055: Admin user cannot create Rules with Rudder 4.3	Released	Nicolas CHARLES	Actions
User story #12111: Make fine-grained API authorization a plugin	Released	François ARMAND	Actions

Related issues 3 (0 open — 3 closed)

Related to Rudder - User story #7893: [API] Expose all configuration options from the WebUI in the API	Rejected	François ARMAND	Actions
Related to API authorizations - User story #13009: Documentation for API authorizations plugin	Released	François ARMAND	Actions
Has duplicate Rudder - User story #5798: Different access levels for API keys / REST API authorizations and rights	Rejected		Actions

Issue # Delay: days Cancel

History
Notes
Property changes
Associated revisions

Actions

Copy link

Updated by François ARMAND over 9 years ago

Hello,

A clearly valid use case !

Some more thought on it:

- do you want more than just read/write authorization granularity ? For example, we may thing that some coniguration details are not at all public (port, passwords - even only hashes, etc)
- as a first workaround, one can configure Rudder Apache to only accept GET method on API url. As we really use verbs semantic, GET === read-only (write is done with PUT or POST).

Actions

Copy link