{"action":"opened","issue":{"url":"https://api.github.com/repos/hashicorp/vault/issues/2220","repository_url":"https://api.github.com/repos/hashicorp/vault","labels_url":"https://api.github.com/repos/hashicorp/vault/issues/2220/labels{/name}","comments_url":"https://api.github.com/repos/hashicorp/vault/issues/2220/comments","events_url":"https://api.github.com/repos/hashicorp/vault/issues/2220/events","html_url":"https://github.com/hashicorp/vault/issues/2220","id":198253523,"number":2220,"title":"support an 'allowed_ou' attribute in PKI backend.","user":{"login":"joemiller","id":377603,"avatar_url":"https://avatars.githubusercontent.com/u/377603?v=3","gravatar_id":"","url":"https://api.github.com/users/joemiller","html_url":"https://github.com/joemiller","followers_url":"https://api.github.com/users/joemiller/followers","following_url":"https://api.github.com/users/joemiller/following{/other_user}","gists_url":"https://api.github.com/users/joemiller/gists{/gist_id}","starred_url":"https://api.github.com/users/joemiller/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/joemiller/subscriptions","organizations_url":"https://api.github.com/users/joemiller/orgs","repos_url":"https://api.github.com/users/joemiller/repos","events_url":"https://api.github.com/users/joemiller/events{/privacy}","received_events_url":"https://api.github.com/users/joemiller/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":0,"created_at":"2017-01-01T01:45:58Z","updated_at":"2017-01-01T01:45:58Z","closed_at":null,"body":"The PKI backend could support an role attribute named `allowed_ou` which would be a regex of allowed `OU`(`organizatonalUnit`) values that would be permitted when issuing certs via the `/sign` and `/issue` endpoints.\r\n\r\nUse case: Our existing internal PKI system utilizes the `OU` field as what is best described as a \"group\" for authorization purposes. For example, a machine may be issued a cert with the subject line containing: `/OU=webserver/CN=host-xyz.fqdn/`. The `CN` identifies the specific identity, in this case the FQDN of the machine, and the `OU` identifies the type or role the machine has. This machine uses this cert for MTLS connections to other services. Those services will recognize the `OU=webserver` from the client cert's subject and grant it access based on what the `webserver` group/role is allowed to perform.\r\n\r\nSimilarly, the `OU` could also be used to identify applications, eg: an instance of an application would be issued a certificate with subject `/OU=backend-foo/CN=<UUID>` where UUID is unique to a specific instance of the app. Applications expecting to communicate with this app would check client connections presented a cert with the correct OU attribute.\r\n\r\nTo show other potential uses of this attribute, another use case is the delegation of cert issuance to \"departmental\" entities. The `OU` attribute, as used in directory services like LDAP, has historically identified some department or administrative grouping of a larger org. This could be modeled with the `allowed_ou` attribute to create roles for specific departments that only allowed administrative members of that department to issue certs with a specific `OU` attribute, eg:\r\n\r\n```\r\nvault write pki/roles/finance-dept allowed_ou='^finance$'\r\n```\r\nAny token/user assigned this role would only be allowed to issue certs containing the `OU=finance` attribute in the subject.\r\n\r\nWould this feature be an acceptable addition to the pki backend?"}}
{"actor":{"display_login":"joemiller"}}