Can we use RBAC plugin in Jenkins CLI to list the groups and the members below it? I am able to find the users for each group using the syntax
java -jar jenkins-cli.jar -s http://localhost:8080/ -i c:\.ssh\id_rsa group-membership path/to/folder GroupName
however, I would like to list all the groups for a particular folder and also list the members in the respective groups. I know later is achievable if we can list the available group names.
Sorry, there is no CLI command currently to list the groups in a given container. You could use get-job path/to/folder to retrieve its raw config.xml, which would include information about defined groups.
Related
Does a list or web-page exist showing what roles are required for all the Openstack CLI commands?
Thanks!
I have a VM for execute ci runner, and two groups.
The runner is installed for one group. Is there any way to share it to the other group.
Otherwise, can i install more runner in one VM server.
The answers to both your questions are yes, but for the first, it depends on if you use gitlab.com or a self-hosted version, and what you have access to.
First for the second part, yes, you can register a second (or third, fourth, ...) running on the same physical host. Just go through the registration process again. Also check the concurrent value in your config.toml file since that controls how many jobs can be running concurrently on that host. If it's lower than the number of runners you have, then they can't all be used at the same time, but sometimes that's on purpose. It's up to you to decide.
For the first part, you can install runners that are shared across the whole instance, but if you're using gitlab.com, only the Gitlab team can do this, so you'd have to use their shared runners. In the Group's CI/CD settings page, you can enable or disable Shared Runners from the gitlab instance for that group.
Otherwise, if you're using self-hosted, you can go to the admin area by clicking the wrench icon in the main nav bar, then go to "Runners" under the Overview tag on the left. On this page you can get the instance's registration token. Any runners registered using this token (opposed to a project's token or a group's token) will be available for all groups and projects on the Gitlab instance. You can also edit existing runners so that they aren't "locked" to a single project from here.
More information can be found in the docs.
Currently, GitLab does not support to assign one runner to multiple groups as a group runner. You could assign the runner to the complete GitLab instance instead (as #adam-marshall already mentioned) but then it will be usable by all members of your GitLab server.
You can try gitlab-multi-group-runner which circumvents this problem by assigning a specific runner to all projects of given GitLab groups with the GitLab API. However, this tool needs administration access to the GitLab server.
I have setup three node secure NIFI cluster and integrated with LDAP for user login .
my doubts
In login-identity-providers.xml can we add multiple USER Search Base of ldap.(i tried by adding multiple usersearchbase but failed)
In LDAP user search should happen on multiple sub domains eg : DC=example1,dc=example,dc=com
DC=example2,dc=example,dc=com
on User-search-base in login-identity-providers.xml
TO achieve mutitenancy in ldap what is the configuration changes we need to make in identity provider.xml
tenant1 user should access process group define for tenant 1 itself and its not access for tenant2 users
From what I can tell, AND Assuming you are using Microsoft Active Directory if you use:
FOLLOW
It may work.
We also sometimes might use the Global Catalog (as then there are no referrals)
I also am guessing that the "empty" parameters should be removed (but I do NOT know how NIFI works).
I would suggest you also do tests with a LDAP Browser to make sure you know what your LDAP tree looks like. We use Apache Studio, but there are others.
More data on if it is Microsoft Active Directory and refer to https://stackoverflow.com/help/how-to-ask
I have installed Sonatype Nexus 3 OSS with Hosted Repository for Docker (Private Registry for Docker). I want to have couple of users, which will be able to pull/push docker images, based on their permissions.
First way, how I can do it - is to create several hosted repositories for docker and then via Securiy -> Privileges use repository-view with such approach configure permissions based on exact repository:
username: repository name: permission:
user1 docker-internal-1 nexus:repository-view-:docker:docker-internal-1:read
user2 docker-internal-1 nexus:repository-view-:docker:docker-internal-1:add
user3 docker-internal-2 nexus:repository-view-:docker:docker-internal-2:read
user4 docker-internal-2 nexus:repository-view-:docker:docker-internal-2:add
This approach works, but it requires having multiple hosted repositories for docker.
My question will be - is it somehow possible to have one singe hosted repository for docker and then configure permissions, based on docker repository namespace?
So let's say I have a repository called docker-internal and then I have such permissions:
username: repository name: permission:
user1 docker-internal nexus:repository-view-:docker:docker-internal/namespace1:read
user2 docker-internal nexus:repository-view-:docker:docker-internal/namespace1:add
user3 docker-internal nexus:repository-view-:docker:docker-internal/namespace2:read
user4 docker-internal nexus:repository-view-:docker:docker-internal/namespace2:add
Unfortunately in Nexus 3 documentation I haven't found a way how I can do it with repository-view permissions, cause they only allow you to specify repository name, but no namespace. Then there is such thing as wildcard, which is described in Sonatype docs like "Wildcard -> These are privileges that use patterns to group other privileges." So I've tried to create some regex pattern like this:
nexus:repository-view:docker:docker-internal/namespace1:read
And unfortunately it doesn't work.
We find a way to combine content-selectors and permission to support image level permissions.
First you have to create two content selectors:
"docker-login-all" with the expression format=="docker" and path=~"/v2/". If you are support v1 protocol too, make sure to create another selector for it.
"docker-foo-selector" with an expression matching the image you want to grant access. For example to select all the releases of foo/bar-linux, the expression is format=="docker" and path=~".*/foo/bar-linux/.*"
The first selector is very important, as without it you are not able to create a rule that allow your users to login.
Then create two privileges based on content-selectors:
"docker-login-all-privilege" based on "Docker-login-all" applied on all the docker registries, with read grants. This will grant the ability to login via docker cli.
"docker-foo-privilege" based on "docker-foo-selector" applied on all the docker registries, with read grants. This will allow your users to pull only foo/bar-linux images.
Then create a role with only the two privileges, and associate it to the users. It should work.
Please be aware of unexpected behaviours when using some commands: https://issues.sonatype.org/browse/NEXUS-12220
Based on answer from Sonatype Nexus support currently it's not possible to do it via wildcard and namespace in docker registry. So the only working way is to use separate docker repositories and repository-view permissions.
Is it possible in any of the existing LDAP servers to edit a schema in one of the editors available? Like JXplorer, Apache Directory Studio, LDAP Admin?
I tried with OpenLDAP and all of the above tools (I run the server with -F option) but it looks like it's not possible to modify schema - add new attributes, add descriptions etc.
I would be grateful if any of you have some experience with this.
Cheers
Some LDAP servers allow (authorized users) to change the schema by sending LDAP modify operation affecting the so-called subschema subentry directly, but not OpenLDAP.
In OpenLDAP you have two possible configuration methods:
Static file configuration usually with schema files being simply included (aka slapd.conf) which requires slapd to be restarted to make configuration changes effective
Dynamic configuration backend back-config (aka cn=config) for which you can also define ACLs restricting access to your LDAP admins
The dynamic configuration method allows to tweak the schema via LDAP making it effective without server-restart. But you have to modify the multiple LDAP entries in sub-tree cn=schema,cn=config which you can do with any generic LDAP client.
Since schema descriptions usually reference other schema descriptions the order is important. Standard LDAP does not know about order of entries beneath an entry or order of attribute values. Therefore OpenLDAP implements an extension specified in draft-chu-ldap-xordered.