So... we could do this, but why are you choosing kerberos here?

Is there any chance we could get you to look at moving to OIDC? It's a lot more flexable, people can then have tokens that have various perms, etc? I am not sure what all your use cases are though...

We have been trying to move our applications to OIDC. I don't know that kerberos will disappear, but OIDC will definitely be around for the long haul.

https://openid.net/connect/

What do you think?

We wanted to add a kerberos auth* support for the Copr command-line
client. The same thing that koji (e.g. koji whoami) does. With the
Fedora 2FA being used more and more, same as fkinit - it sounds like
something we want.

The major motivation is that Copr has only the ~/.config/copr API token
for the command-line tool now - and the token needs to be regenerated from
time to time. For the wast majority of Copr cli use-cases, using fkinit
token would be just enough, safe, and simple.

For the web-UI login, I think it is not a bad idea to support direct
kerberos log-in too (alongside the current ipsilon redirect, which works -
but is slower).

That said, from the FAQ document I'm not sure OIDC matches our needs?

Has there been any progress already?
I agree with Pavel's opinion, now we would be very happy if you could create the keytab for us.

I'm still not completely sure, @kevin - do you think this a valid use-case for kerberos?

I was out on PTO last week.

Yeah, I think we can just do this for now... I think OIDC is better/more fine grained, but we allow kerberos for fasjson api, so I suppose if it's good enough for that, it's ok for this.

I'll try and move this forward this week. Sorry for the delay.

I was going to process this, but then I realized, you should be able to just do this in ansible?

You should be able to add:

- role: keytab/service
  kt_location: /etc/copr/copr-api-keytab
  service: copr-api
  owner_user: whatever
  owner_group: whatever
  host: copr-fe-whatever

I think this will work even though the host isn't an ipa client (It will make a host for it as part of the keytab role).

Can you just give that a try? The dev one should work with staging ipa as long as env = staging there.

It's often very surprising what we can do ourselves with the ansible.git library. Thank you for the hint. /etc/httpd/conf.d/copr-frontend-http-api.keytab

This can be closed (I can't do that myself).

Re-opening this issue because it hasn't been completely resolved. Keytab is created on the stage instance of copr, but we can't create a keytab that would also work for the alias.
As Kevin mentioned we need to modify roles/ipa/service/tasks/main.yml to optionally accept a list of principal aliases for the service, then delete the service and re-create it via ansible.

Commit 3f5cb871 relates to this ticket

I've merged the PR to add handling for principal alias. Can you try it now? also do we need to merge https://pagure.io/fedora-infra/ansible/pull-request/672 ?

Thank you, I tried it and there was a bug in the code that I fixed. We will merge https://pagure.io/fedora-infra/ansible/pull-request/672 once I try it with a new keytab file.

When I ran the playbook on batcave (sudo rbac-playbook -l copr-fe-dev.aws.fedoraproject.org groups/copr-frontend.yml), it failed with the error message {"changed": false, "msg": "service_add_principal: HTTP/copr-fe-dev.aws.fedoraproject.org: This entry already exists"}. This is strange because I'd expect that the module is idempotent so if the entry already exists it doesn't change anything. I don't know if it is necessary to name the service copr-api as mentioned here https://pagure.io/fedora-infra/ansible/pull-request/672#comment-155187. The service name was changed in https://pagure.io/fedora-infra/ansible/c/afa1a1fc2a4d329d38e00b5d8168c7c37b8de4ca?branch=main. Can someone please delete the service entry on {{ ipa_server }} so I can run the playbook again?

For your information, I opened the issue https://github.com/freeipa/ansible-freeipa/issues/663. This is relevant for anyone using the ipa role to know that this situation can occur.

So, this is a bug in the module. ;(

I can delete the service entry for now. (done)

Or is there some other way to work around it you can think of?

Thank you :)
I added this check https://pagure.io/fedora-infra/ansible/pull-request/846

I ran playbook for copr dev frontend yesterday and it failed with the same error message. Can you please check that you properly deleted the service and run copr playbook for dev frontend as sudo rbac-playbook -l copr-fe-dev.aws.fedoraproject.org groups/copr-frontend-cloud.yml? It would help me because you would see if the service is really deleted.

Ah. I see the problem. copr-fe-dev is using our staging ipa/account system. :)

So, I removed the ones in stg and ran the playbook, and it completed. With no changes. ;(

Ah, there's a when: false on it. Modified that to let me pass a variable to run it and... it completed.

please check it out.

Ah. I see the problem. copr-fe-dev is using our staging ipa/account system. :)

No :( because we wanted to debug the mail+pass login loop problem I re-configured copr few weeks back. So the last playbook runs we executed run against production IPA? Was that the problem?
Anyway, we are done with the corresponding problem, so I reverted now. Sorry for the confusion.

So, I removed the ones in stg and ran the playbook, and it completed. With no changes. ;(

Hm, because I again disabled task in our playbook recently, just to
not have the playbook broken in case anyone else wanted to run it.

Ah, there's a when: false on it. Modified that to let me pass a variable to run it and... it completed.

Yeah, that ... but the rbac-playbook doesn't allow me to specify variables?
Unfortunately, that was run against production IPA, I've removed the "when false"
condition now ... playbooks cucceeds, but no change:

TASK [keytab/service : Set keytab permissions] *****************************************************************************************************************************************************************************************************************************************************************
Wednesday 27 October 2021  07:46:05 +0000 (0:00:00.331)       0:02:33.614 ***** 
Wednesday 27 October 2021  07:46:05 +0000 (0:00:00.331)       0:02:33.613 ***** 
ok: [copr-fe-dev.aws.fedoraproject.org]

It works!
I ran
KRB5_TRACE=/dev/stderr curl --negotiate -u : https://copr-fe-dev.cloud.fedoraproject.org/krb5_login/fedoraproject
and it finished with

...
[50255] 1635335371.943377: TGS reply is for schlupov@STG.FEDORAPROJECT.ORG -> HTTP/copr-fe-dev.aws.fedoraproject.org@STG.FEDORAPROJECT.ORG with session key aes256-cts/65BE
[50255] 1635335371.943378: TGS request result: 0/Success
[50255] 1635335371.943379: Received creds for desired service HTTP/copr-fe-dev.aws.fedoraproject.org@STG.FEDORAPROJECT.ORG
[50255] 1635335371.943380: Storing schlupov@STG.FEDORAPROJECT.ORG -> HTTP/copr-fe-dev.aws.fedoraproject.org@ in KCM:1000
[50255] 1635335371.943382: Creating authenticator for schlupov@STG.FEDORAPROJECT.ORG -> HTTP/copr-fe-dev.aws.fedoraproject.org@, seqnum 949118501, subkey aes256-cts/E5E8, session key aes256-cts/65BE

and on our devel website I am logged in using krb5-login in the upper right corner.
klist shows
Default principal: schlupov@STG.FEDORAPROJECT.ORG
Ticket server: HTTP/copr-fe-dev.aws.fedoraproject.org@STG.FEDORAPROJECT.ORG

Thank you for your help and patience :)

Awesome. So, whats left here? just enabling in prod? Is there anything further you need from our side?

I rebased this PR https://pagure.io/fedora-infra/ansible/pull-request/672 so it can be merged now. I'd really appreciate help with this pull request https://pagure.io/fedora-infra/ansible/pull-request/846.

ok. 672 looks ok to me. Can you all merge it and run playbook when you want to try it out?

I guess we closed 846 as it's not needed...

Once 672 is in, I guess we can close this?

672 merged. Closing this issue, it's been resolved.