You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When a pod has no service, if no scope is configured in its secret pvc annotation or the scope is only a pod, the pod will not start properly.
The logic for secret-csi to generate keytab via pvc is: pod uses a temporary volume to make the secret storage class supply keytabs. After receiving the parameters configured in the pvc annotation, secret-CSI first creates the corresponding principals in kerberos and then generates keytabs containing these principals.
There is a special logic when generating a principal for a pod, when scope is a pod, and if the pod has a service association, then the hostname of the principal (e.g. foo/<svc-name>.svc.cluster.local@EXAMPLE.COM) is svc-name, and if there is no service, pod ip will be tried.
The key point is here, the logic of the pod is that the resource association is complete, the pod will start, and assign ip, if pvc is not ready, then the pod will not have IP, so in the case of pod no service and scope is pod, It's impossible to get the pod ip.
In addition, this situation is also more special, first of all, pod no service is rare, or only in the case of client access.
The current logic causes the csi program logic to fail, rather than giving a warning or providing an empty file to allow the pod to run properly, so this behavior is a BUG for secret-operator and csi.
What we need to discuss is that it is possible to use keytab only when the pod has no service. How should we deal with it? Whether csi is allowed to supply keytab for this situation, or to supply keytab normally with additional parameters, or to allow principals without host names to exist.
A solution that specifies headless services for Pods. When a pod is created, the specified subdomain is displayed, or a subdomain is specified for the pod in the pod template for deployment.
whg517
changed the title
[Bug]: keytab cannot be supplied when pod does not assign service and the value of scope is pod
[Bug]: keytab cannot be provisioned when pod does not assign service and the value of scope is pod
Aug 5, 2024
Describe the bug
When a pod has no service, if no scope is configured in its secret pvc annotation or the scope is only a pod, the pod will not start properly.
The logic for secret-csi to generate keytab via pvc is: pod uses a temporary volume to make the secret storage class supply keytabs. After receiving the parameters configured in the pvc annotation, secret-CSI first creates the corresponding principals in kerberos and then generates keytabs containing these principals.
There is a special logic when generating a principal for a pod, when scope is a pod, and if the pod has a service association, then the hostname of the principal (e.g.
foo/<svc-name>.svc.cluster.local@EXAMPLE.COM
) is svc-name, and if there is no service, pod ip will be tried.The key point is here, the logic of the pod is that the resource association is complete, the pod will start, and assign ip, if pvc is not ready, then the pod will not have IP, so in the case of pod no service and scope is pod, It's impossible to get the pod ip.
In addition, this situation is also more special, first of all, pod no service is rare, or only in the case of client access.
The current logic causes the csi program logic to fail, rather than giving a warning or providing an empty file to allow the pod to run properly, so this behavior is a BUG for secret-operator and csi.
What we need to discuss is that it is possible to use keytab only when the pod has no service. How should we deal with it? Whether csi is allowed to supply keytab for this situation, or to supply keytab normally with additional parameters, or to allow principals without host names to exist.
Have you searched existing issues? 🔎
I have searched the existing issues
Reproduction
Screenshot
No response
Logs
No response
System Info
Severity
I can work around it
The text was updated successfully, but these errors were encountered: