search

jenkinsci / kubernetes-operator

Kubernetes native Jenkins Operator
https://jenkinsci.github.io/kubernetes-operator
Other
602 stars 236 forks source link

Add LDAP/AD integration instruction #133

Closed tumevoiz closed 3 years ago

tumevoiz commented 5 years ago

As written here - https://github.com/jenkinsci/kubernetes-operator/issues/120, there is need to add LDAP/AD integration instruction in customization docs:

https://github.com/jenkinsci/kubernetes-operator/blob/master/website/content/en/docs/Getting%20Started/v0.2.0/customization.md

and here

https://github.com/jenkinsci/kubernetes-operator/blob/master/website/content/en/docs/Getting%20Started/v0.1.1/customization.md

Issues that may have relevant info: #208 #191 #192

yoshi314 commented 5 years ago

What i do is alter the created user login+password for the jenkins-operator to an account that exists in LDAP and apply a following yaml file via JCaSC : 

  1-configure-ldap.yaml: |
    # ldap - ldap configuration must be provided
    jenkins:
      systemMessage: "LDAP configured"
      securityRealm:
        ldap:
          configurations:
            - server: "ldap://ldap.server"
              groupMembershipStrategy:
                fromUserRecord:
                  attributeName: "memberOf"
              rootDN: "dc=some,dc=company,dc=com" # mandatory
              managerDN: "CN=ldapmanager,OU=sysusers,OU=Users,OU=sysaccounts,DC=some,DC=company,DC=com"
              managerPasswordSecret: "sekrit"
              userSearchBase: 
              userSearch: "sAMAccountName={0}"
              groupSearchBase: 
              groupSearchFilter: "sAMAccountName={0}"

hope this helps

pawelprazak commented 4 years ago

btw might want to also take look at #192 for things to clarify in the docs

bechampion commented 4 years ago

The documentation links above return 404 , I've been looking at the code today , i can see where the random credentials are generated etc. Still quite unclear what happens after install AD or LDAP plugins on jenkins. Once you install LDAP or AD plugins , are you supposed to change the kube-secret that contain the credentials? that will trigger an userpasswd hash mismatch and the jenkins pod will be recreated. But then i seem to end up in a reconcile loop , is like the jenkins controller doesn't really pick up the credentials from the secret anymore?

Has anybody had some success with this?

tomaszsek commented 4 years ago

Instructions:

yoshi314 commented 4 years ago

The documentation links above return 404 , I've been looking at the code today , i can see where the random credentials are generated etc. Still quite unclear what happens after install AD or LDAP plugins on jenkins. Once you install LDAP or AD plugins , are you supposed to change the kube-secret that contain the credentials? that will trigger an userpasswd hash mismatch and the jenkins pod will be recreated. But then i seem to end up in a reconcile loop , is like the jenkins controller doesn't really pick up the credentials from the secret anymore?

Has anybody had some success with this?

i replaced the jenkins-operator credential with one that has correct login and password for ldap. The token has to be left as-is, so you'll have to dump the secret first , edit it and reapply.

bechampion commented 4 years ago

Hey all , i have it working , thanks so much for the help , two thigns to notice , it worked for me with these plugins version:

  - name: configuration-as-code-support    
    version: "1.18"
    version: "1.21.0"    
  - name: ldap    
    version: "1.21"

The other thing to say is once you change the password on the secret there's a reconciliation that happens and the pods get recreated.

BogdanSorlea commented 4 years ago

What i do is alter the created user login+password for the jenkins-operator to an account that exists in LDAP and apply a following yaml file via JCaSC :

How exactly do you alter the jenkins-operator password to the one you set-up in LDAP (if I understand this correctly)? @yoshi314

save the username and password to the credentials secret

It is unclear what credentials secret and how this gets plugged in for jenkins-operator to use @tomaszsek

if you guys could clarify, including with examples, it would help a lot. what I understand is that I create in our LDAP a jenkins-operator user with a "fixed" password, password which gets written to some Secret k8s resource that somehow gets plugged in such that the operator pod (and I guess the jenkins pod as well, until LDAP connection is set-up) knows about it and uses it. but it's very unclear how this is achieved. examples welcomed.

tomaszsek commented 4 years ago

@BogdanSorlea I've updated the comment with the secret example https://github.com/jenkinsci/kubernetes-operator/issues/133#issuecomment-555976832. We will update the documentation with the step by step instruction.

BogdanSorlea commented 4 years ago

cool, thanks. I also found in the meantime the secret via kubectl get secrets, but this gives better clarity.

BogdanSorlea commented 4 years ago

the last step does not seem to work,

WARNING: Configuration-as-Code can't handle type class hudson.security.GlobalMatrixAuthorizationStrategy

(on jenkins pod) and

2019-12-06T12:52:14.920Z    WARN    controller-jenkins  groovy/groovy.go:53 user-casc Source 'jenkins-config' Name '1-configure-ldap.yaml' groovy script execution failed, logs :
java.lang.IllegalStateException: No configurator implementation to manage class hudson.security.GlobalMatrixAuthorizationStrategy
    at io.jenkins.plugins.casc.impl.configurators.HeteroDescribableConfigurator.lambda$forceLookupConfigurator$8(HeteroDescribableConfigurator.java:137)
    at io.vavr.control.Option.getOrElseThrow(Option.java:351)

(on operator pod), code being

jenkins:
  authorizationStrategy:
    globalMatrix:
      grantedPermissions:
        - "Overall/Administer:authenticated"
        - "Overall/Administer:jenkins-operator"

and plugins are

    basePlugins:
      - name: github
        version: 1.29.5
      - name: kubernetes
        version: 1.19.3
      - name: workflow-job
        version: "2.35"
      - name: workflow-aggregator
        version: "2.6"
      - name: git
        version: 3.12.1
      - name: job-dsl
        version: "1.76"
      - name: configuration-as-code
        version: "1.32"
      - name: configuration-as-code-support
        version: "1.19"
      - name: kubernetes-credentials-provider
        version: 0.12.1
    plugins:
      - name: greenballs
        version: '1.15'
      - name: ldap
        version: '1.20'
      - name: simple-theme-plugin
        version: 0.5.1
      - name: skip-certificate-check
        version: '1.0'

there is obviously something I'm missing here - and although I searched around for the error, there was no clear fix in sight @tomaszsek - do you know what the problem might be / could you point me to the updated documentation, when it will be available? anyone else - help is appreciated

thanks

LE: seems it might be a case of a missing plugin in the plugins list above:

     - name: matrix-auth
       version: '2.5'

was misleading because without it, after login, there was the option to matrix-config the jenkins access (from the UI), so I assumed it was already bundled with Jenkins. either that, or there was something about the version that was off

BogdanSorlea commented 4 years ago

I hereby confirm that this worked - https://github.com/jenkinsci/kubernetes-operator/issues/133#issuecomment-555976832

yoshi314 commented 4 years ago

@BogdanSorlea i've setup the permissions in web ui, and then exported them via configuration as code plugin. I used per-project permissions.

Here is a relevant snippet 

 3-permission-matrix.yaml: |
    jenkins:
      authorizationStrategy:
          projectMatrix:
            permissions:
            - "Agent/Build:authenticated"
            - "Agent/Build:jenkins-operator-dev"
            - "Agent/Build:m15kowal"
            - "Agent/Configure:authenticated"
            - "Agent/Configure:jenkins-operator-dev"
            - "Agent/Configure:m15kowal"
            - "Agent/Connect:authenticated"
            - "Agent/Connect:jenkins-operator-dev"
            - "Agent/Connect:m15kowal"
            - "Agent/Create:authenticated"
            - "Agent/Create:jenkins-operator-dev"
            - "Agent/Create:m15kowal"
            - "Agent/Delete:authenticated"
            - "Agent/Delete:jenkins-operator-dev"
            - "Agent/Delete:m15kowal"
            - "Agent/Disconnect:authenticated"
            - "Agent/Disconnect:jenkins-operator-dev"
            - "Agent/Disconnect:m15kowal"
            - "Credentials/Create:authenticated"
            - "Credentials/Create:jenkins-operator-dev"
            - "Credentials/Create:m15kowal"
            - "Credentials/Delete:authenticated"
            - "Credentials/Delete:jenkins-operator-dev"
(....)
tomaszsek commented 4 years ago

Please remember that user for the jenkins operator have to have admin rights.

yoshi314 commented 4 years ago

Yes, the exported yaml was a bit long, so i cut it short here.

apogrebnyak commented 4 years ago

There is a problem with using jenkins-operator-credentials-<cr-name> secret.

And the problem is that it stores 2 generated secret values for token and tokenCreationTime.

I am using terraform for kubernetes secret management. On initial TF deploy everything is fine, however on consequent deploys, when TF tries to reconcile jenkins-operator-credentials-<cr-name>, both token and tokenCreationTime get deleted, with disastrous consequences (basically breaking operator->cr communication channel).

I propose moving token and tokenCreationTime to its own secret, so we can specify custom credential secrets in case of LDAP configuration.

VGerris commented 3 years ago

since it seems when LDAP is down, login is impossible, a way to deal with that would be appreciated too. And more preferable of course, just internal admin users working. Besides that, ldaps with self signed certs does not work. It would be great if there is good documentation on where to store a self signed CA (like from FreeIPA) and add that to a Java Keystore that Jenkins can use to do LDAPS, or better yet, an option to skip cert checking (like Atlassion products have)

Bakies commented 3 years ago

FWIW Since I was having trouble following the instructions in https://github.com/jenkinsci/kubernetes-operator/issues/133#issuecomment-562056816 I'll detail what I did. I was having trouble with the operator overriding the LDAP settings I had in my CasC yaml when it ran the script in the configmap jenkins-operator-init-configuration-crname. I ended up just mounting an empty dir in the jenkins cr with the path /var/lib/jenkins/operatorUserCreated so the script doesn't change the security realm settings. I did try to overwrite the configMap to just not have any scripts, but I guess the operator changes it after my kustomize build | kubectl apply

stale[bot] commented 3 years ago

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. If this issue is still affecting you, just comment with any updates and we'll keep it open. Thank you for your contributions.

yoshi314 commented 3 years ago

what i do nowadays is apply a configmap with ldap credentials for operator account first, and then deploy helm package which also pulls in userconfig for jenkins that sets up ldap auth.

That works for me.