potiuk commented on PR #33680: URL: https://github.com/apache/airflow/pull/33680#issuecomment-1692506255
> I'll add, the orphaned secrets problem does worry me a bit. Doesn't feel great that we can leave stuff in secrets sitting around potentially forever. I get why folks have chosen to build it in custom wrappers, but it worries me making it a product thing 🤷♂️. > > And I don't have a good mitigation or alternative here. We can't even have the scheduler do occasional cleanup, since we can go create these things in many k8s contexts too. It indeed crossed my mind too, and it is quite a bit worrying, I quite agree. I know @eladkal 's team approach was exactly this, they had jobs that cleaned old secrets. Unfortunately K8S has no auto-cleaninig of secrets. It would be a great feature to have. But we don't.... However there is - likely - a way - not active, but passive removal of such potential secrets. I think we can reasonably assume, that we have a continuous stream of tasks executed "within" the same K8s context. Airflow is a "periodic" scheduler - means that if we run some task today, we will run the same task tomorrow (roughly speaking). And if we had enouhg permissions to create a secret in one context, we should have enough permissions to delete the secrets when we use the same context again. I think, we could have a convention (label) for the secret that could tell "if the pod id mentioned in the label is not running any more we can delete such secret". And we could just do such cleanup every time new task is started in a context. That would make such secretes "eventually deleted" - and if you ask me, sounds like good-enough for product. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
