I'm trying to authenticate via kerberos in AWX. I'm hosting AWX in Azure Kubernetes Services. KDC that we use is ldap. I'm able to communicate with the ldap server with ping and over port 88 with telnet when executing from the container itself. I'm not sure what more I can do to test this and the log files are empty.
I've added krb5.conf file and krb5.keytab file to the Task/Web containers. I've tried with and without keytab. I've tried changing the cache to a file rather than keyring.
apiVersion: v1
kind: ConfigMap
metadata:
name: {{ include "awx.fullname" . }}-application-config-krb5
labels:
app.kubernetes.io/name: {{ include "awx.name" . }}
helm.sh/chart: {{ include "awx.chart" . }}
app.kubernetes.io/instance: {{ .Release.Name }}
app.kubernetes.io/managed-by: {{ .Release.Service }}
data:
krb5.conf: |
# Configuration snippets may be placed in this directory as well
includedir /etc/krb5.conf.d/
[logging]
default = FILE:/var/log/krb5libs.log
kdc = FILE:/var/log/krb5kdc.log
admin_server = FILE:/var/log/kadmind.log
[libdefaults]
dns_lookup_realm = false
ticket_lifetime = 24h
renew_lifetime = 7d
forwardable = true
rdns = false
default_realm = MYDOMAIN.COM
default_ccache_name = KEYRING:persistent:%{uid}
[realms]
MYDOMAIN.COM = {
kdc = ldap.mydomain.com
admin_server = ldap.mydomain.com
}
[domain_realm]
.mydomain.com = MYDOMAIN.COM
mydomain.com = MYDOMAIN.COM
I get same same error no matter what configuration I try. Curious what I'm doing wrong. I can get this to function with a working kerberos configuration on a VM with AWX running locally in docker, however, I can't get it to work in AKS. Not sure if this is specific AKS or Kubernetes in general.
Error:
kinit: Cannot contact any KDC for realm 'MYDOMAIN.COM' while getting initial credentials
The error indicates that server where you see that error cannot contact the KDC. According to your config, that is : ldap.mydomain.com . You need to verify that you have the Kerberos setup configured properly and that DNS is setup correct too. Kerberos checks default records to contact the KDC. Obviously the ports outgoing and incoming to the server have to be accessible too.
Troubleshoot is from the running instance as a common Kerberos setup is the best advice I can give based on the limited information.