knative deployer failed to update the Knative Service: referenced Secret xxxis not present
Closed this issue · 4 comments
Hi,
I got this issue when re-reploying a service:
func deploy --remote
...
arning: git settings are only applicable when running with --remote. Local source code will be used.deploy error: knative deployer failed to update the Knative Service:
referenced Secret "bing-apikey" is not present in namespace "agent-less"
Error: knative deployer failed to update the Knative Service:
referenced Secret "bing-apikey" is not present in namespace "agent-less"
However, the secret does exist in this namespace:
kn secret list -n agent-less
NAME TYPE
bing-apikey Opaque
I have a env using secret in the func.yaml:
run:
envs:
- name: BING_API_KEY
value: '{{ secret:bing-apikey:apiKey }}'
This issue only happens when re-reploying a function. The workaround is to delete the existing function first before deploy it:
func delete -n agent-less bing-search-tool
Removing Knative Service: bing-search-tool
Removing Knative Service 'bing-search-tool' and all dependent resources
func deploy --remote
This does seem like a bug if you can work around the issue by removing/deploying again.
after debugging, I find the cause is that the default service account does not have permission to get the secret.
secrets "xxx" is forbidden: User "system:serviceaccount:agent-less:default" cannot get resource "secrets" in API group "" in the namespace "agent-less"
func/pkg/knative/deployer.go:
func checkResourcesArePresent(ctx context.Context, namespace string, referencedSecrets, referencedConfigMaps, referencedPVCs *sets.Set[string], referencedServiceAccount string) error {
errMsg := ""
for s := range *referencedSecrets {
_, err := k8s.GetSecret(ctx, s, namespace)
if err != nil {
// here
errMsg += fmt.Sprintf(" referenced Secret \"%s\" is not present in namespace \"%s\"\n", s, namespace)
}
}
Thanks for running through the debugging!
From my experience, by default a Function deployed (which is just a regular service) has access to secrets in the namespace to which it was deployed. This may require a change to the cluster's configuration, or way to specify the permissions with which it executes.
Yes, it could be fixed easily by adding permission to the service account. Maybe we can improve the error message by adding something like the original error so that it will not be confusing.