https://rancher.com/ logo
Join Slack
Powered by
Does anyone know which CRD houses the 'members' of...
# general
b
Does anyone know which CRD houses the 'members' of a project? It doesn't appear to be on the project itself..
c
There isn't one. Its an annotation on the namespace. You "create" a project by annotating a namespace.
b
maybe my question wasn't clear, but what I was looking for is 
ProjectRoleTemplateBinding
the string of connections for this stuff is a rats nest 😄 I'm trying to determine if I can through declarative measures add groups to projects etc
but I want to do it all by sane names and ldap groups etc across multiple clusters
c
Ahh, users who have access to a project.
b
yeah, is 
members
not the correct term?
proejcts do have a crd though just so we're clear
Copy code
apiVersion: <http://management.cattle.io/v3|management.cattle.io/v3>
kind: Project
metadata:
  name: p-rvrzt
  namespace: c-qhl8v
spec:
  clusterName: c-qhl8v
  containerDefaultResourceLimit: {}
  displayName: ambassador
  namespaceDefaultResourceQuota:
    limit: {}
  resourceQuota:
    limit: {}
    usedLimit: {}
I understand the namesapces are bound to the project via an annotation on the ns in the target cluster
s
rancher follows kube rbac principals and uses 
bindings
to connect 
roles
to 
subjects
(principals - users or groups) in a target (global, cluster, project). subjects are then members of that target. project roles can be seen via the Users & Authentication --> Role Templates --> Project/Namespaces tab user/group principals can be seen via the Users & Authentication --> Users|Groups pages 
projectroletemplatebinding
require a projectId, roleTemplateId and a userPrincipalId|groupPrincipalId. note though, this is generally an internal resource and is liable to change without notice (though hasn't in a long time). there are plans to migrate this to the new Rancher Public API, however won't be for a few releases at least
b
Yeah, I am using all of those already. The template binding was the missing piece. Interestingly, I can put only the active directory piece in there and rancher seems to make the linkage to the internal ids on its own.
In general trying to keep settings symmetrical across disperse rancher installs is the challenge. I will probably need to create my own operator which will normalize things based off of internal labels or similar. For example I don’t want SEs to need to understand the various cluster ids but I want them to be able to put namespaces in git (argocd) and bind it to a given project. In argocd that same ns could land in multiple clusters in the same rancher or multiple clusters across disperse rancher installs.
So I want SEs to indicate (this ns should be in project x), but the key syntax rancher uses is cluster:project
So I either need to maintain a giant list of mapping in my rendering side that will translate for them, or I have them use a custom internal label which is read by an internal operator and it does the translation.
Open in Slack
PreviousNext
Powered by