Tuleap 16 est là ! Assistez à l'événement virtuel le 17 octobre à 10h30. Inscrivez-vous ici !

    •  
      story #22708 flexibility in the management of Tuleap Configuration
    Summary
    Empty
    flexibility in the management of Tuleap Configuration
    Empty

    As of today, most of Tuleap code still rely on some files to be written on the file system for the configuration (like /etc/tuleap/conf/local.inc)

    It served us well but is no far from ideal in a Cloud/Container world where modifying the content of an image is not a good practice (in addition to a PITA).

    Prior to this there is some clean-up needed:

    • all non PHP code (python & perl wrappers mainly) must be updated to exec tuleap config-get instead of trying to parse local.inc
    • usage of PluginFileInfo to gather variables defined for a plugin should be moved to ForgeConfig

    Get

    The goal is to be able to configure/override all Tuleap variables in a flexible manner. The proposal is to introduce a precedence for variable fetching:

    1. Database
    2. $file.inc
    3. Environment Variable
    4. $file.inc.dist (or code based default, see below)

    With this approach we can keep the goo'old $file.inc for existing installation while going /etc/tuleap less in containers.

    The proposal for Environment Variables is to prefix all of them with TULEAP_ (eg TULEAP_SYS_DEFAULT_DOMAIN would override $sys_default_domain set in local.inc). If the environment variable starts with TULEAP_FILE_XXX then the value is assumed to be read from a file (eg. TULEAP_FILE_SYS_DBPASSWD would set the value of $sys_dbpasswd with the content of the file).

    A special case should be taken into account for the DB password secret (because it can be provided by ENV or by file.inc but not by DB).

    WARNING: we also need to take into account the existing code that relies on /etc/tuleap/conf/local.inc to be present to decide if Tuleap was already installed or not (e.g. startup sequence of containers).

    Management of configuration keys

    The loading of values should no longer depends on $file.inc.dist:

    • All configuration keys should be transferred to source code with constants.
    • Whenever possible, the keys are associated to classes that are related to the variable
    • New attribute is added to defined the default value (existing default values in DB should be removed from database_initvalues.sql but existing platforms with values already set won't be "purged").
    • New attribute to distinguish configuration keys that old secrets.
      • secrets will be stored encrypted in DB
      • secrets won't be leaked with tools to get all variables (eg tuleap config-get --all to be added)

    Special case of secrets not associated to variables

    There are 2 secrets ATM that are not in a variable:

    • /etc/tuleap/conf/encryption_secret.key
      • Can be provided as ENV or ENV_FILES, otherwise it's generated on the fly
    • /etc/tuleap/plugins/prometheus_metrics/etc/metrics_secret.key
      • Introduce a new configuration key for this so it can be managed like other secrets (ENV/ENV_FILE or encrypted in DB)

    Set

    When the new GET sequence is in place, the change of variables must also be updated.

    The proposal is to allow tuleap config-set to write any variables in the database.

    This approach combined to the new GET sequence would allow to manipulate all variables with "config-set" (as of today it's limited to variables that are "database native").

    It's, again, far from ideal to mandate an SSH connection to a running environment to change a variable. So, in addition to the storage modification, a new REST route to manipulate the variables is introduced (definition to be precised).

    Empty
    Thomas Cottier (tcottier)
    Status
    Docker images
    Ready (stalled)
    Development
    • [ ] Does it involves User Interface? 
    • [ ] Are there any mockups?
    • [ ] Are permissions checked?
    • [ ] Does it need Javascript development?
    • [ ] Does it need a forge upgrade bucket?
    • [ ] Does it need to execute things in system events?
    • [ ] Does it impact project creation (templates)?
    • [ ] Is it exploratory?
    Empty
    Details
    #22708
    Manuel Vacelet (vaceletm)
    2023-01-18 15:43
    2021-09-09 13:41
    3509

    References
    Referencing story #22708

    Git commit

    tuleap/tuleap/stable

    chore(forge-config): convert ConfigDao to EasyDB d6548abeb4
    chore(forge-config): Clean-up ForgeConfig loading 860293337c
    chore(forge-config) Python code, bye bye local.inc 5a1e201eb8
    chore(forge-config)!: dump contains LDAP variables 5521dc319d
    chore(forge-config) Load vars from JSON in perl 6c2e8c2c26
    chore(forge-config): Remove last usage of direct parsing of local.inc 826d0ebf13
    feat(forge-config): DB host name loaded from env 6c322d646e
    feat(forge-config): list keys that cannot be modified 60188bef0f
    feat(forge-config) all database settings can be defined from ENV 2f9a124487
    chore(forge-config) Only look at public constants fc6a28e456
    chore(forge-config): Extract database configurator 44708951f0
    chore(forge-config) Unify database initialization 64eeca0bbb
    feat(forge-config): Seed docker image with DB passwords 4591c5ee7c
    chore(forge-config): Generate database.inc without .inc.dist 5d76f9adb3
    chore(forge-config): Use ForgeConfig to carry database configuration 013ee27b6d
    chore(forge-config): Transfer dbauth user & password to database cb732eb32e
    chore(forge-config) Write local.inc with TuleapCfg df3c04d595
    chore(forge-config): TuleapSetup does the complete setup 563b27155a
    Remove usage of ForgeConfigSandbox in BackendSVNTest integration tests 4db093ede7
    fix(forge-config): setup local.inc can no longer rely on sed d626ed34d3
    fix(forge-config): Site secret should be generated at site install eeab7d013a
    feat(forge-config): Set admin email in the docker image 31320ad744
    chore(forge-config): Rename GetWhitelistedKeys event c3c9a23c4e
    feat(forge-config): Default value from attributes (core) 696c68578b
    feat(forge-config): Default value from attributes (plugins) ca9c3406c2
    fix(forge-config): Propagate config for TULEAP_SYS_DBPORT 86ae3ecb53

    Follow-ups

    User avatar
    • Acceptance criteria
      Something went wrong, the follow up content couldn't be loaded
      Only formatting have been changed, you should switch to markup to see the changes
    • Category set to Site admin
    User avatar
    Thomas Gerbet (tgerbet)2022-04-08 15:29

    gerrit #25621 (Propagate config for TULEAP_SYS_DBPORT) integrated into Tuleap 13.7.99.106.

    Deployment guide should probably be updated to mention the removal of TULEAP_DB_SSL_MODE and TULEAP_DB_SSL_CA.


    • Category set to
    User avatar

    Current status (as of Tuleap 13.7.99.16):

    • Tuleap regular install & container sequence are aligned (and FWIW most of the test init sequence too)
    • It's possible to define init values (DB params, a few parameters like admin email, password or platform name)

    The possible next steps:

    • define secrete related variables with a file (eg TULEAP_SYS_DBPASSWD_FILE=/path/to/secret)
    • move all configuration keys from local.inc to database

    One bump road identified: it will be tough to have default values defined in the code base due to the way configuration is loaded because in pre.php it's at the very beginning of the sequence, before the plugins are loaded so it means that default values for plugins will have to be loaded "later". That might even be trickier to avoid having to load all plugins to load the variables when plugins are not needed (caching of plugin load).

    User avatar

    So as a start, I'm going to transfer to TuleapCfg the Tuleap setup that comes after having a DB installed (that's already almost completely handled by tuleap-cfg anyway). This way I will have more flexibility to access/define variables and the installation & configuration of docker images and OnPrem will stay the same.

    User avatar

    I introduced SITE_ADMINISTRATOR_PASSWORD to inject that secret. I was wondering if it should be a one time thing or if we should take it as a new tuleap parameter

    It can only work as a one time thing on the first setup no? I might be missing something but after the initial setup we might have different and multiple site administrators accounts.

    That's correct. Actually I don't know what are the good practices related to that. I don't know if it's a common thing for orchestrator to differenciate "application init" and regular runs. Will have to check that.

    I'm not sure about saving all the things we pass via an env variable to a file. Maybe we could meet in the middle: everything tagged as ConfigCannotBeModified goes to a file, everything else is saved in the DB. Also, it's going to be annoying to serialize those settings in the format currently expected by database.inc. Since it is not something we expect humans to modify we can probably save it with a var_export() (or the fancy Symfony implementation).

    You are right. I'll propose a different strategy.

    User avatar
    Thomas Gerbet (tgerbet)2021-10-27 10:42

    gerrit #24354 integrated into Tuleap 13.1.99.68.

    I introduced SITE_ADMINISTRATOR_PASSWORD to inject that secret. I was wondering if it should be a one time thing or if we should take it as a new tuleap parameter

    It can only work as a one time thing on the first setup no? I might be missing something but after the initial setup we might have different and multiple site administrators accounts.

    Based on that, I was wondering if the strategy related to environment variables shouldn't change a bit. What do you think about using ENV as a source of config values that would be written (for instance in database.inc for database params) and then Tuleap just use that file as it always did ?

    Good point for the stuff executed through sudo (we could fix it but it is pretty sure we are going to miss some things...).

    I'm not sure about saving all the things we pass via an env variable to a file. Maybe we could meet in the middle: everything tagged as ConfigCannotBeModified goes to a file, everything else is saved in the DB.

    Also, it's going to be annoying to serialize those settings in the format currently expected by database.inc. Since it is not something we expect humans to modify we can probably save it with a var_export() (or the fancy Symfony implementation).

    User avatar

    In order to illustrate what I have in mind, I made a quick and dirty implementation of the previous proposal that can be seen at gerrit #24338 The good thing is that, we're not "too far" from sth that can work (at least for the DB parameters): tuleap (after a quick conf of fpm that is not visible in this commit) can be installed and run only with environment variables that maps what comes from database.inc.

    On top of that, I went a little bit further by making some related secrets (mysql tuleapadm password and site admin password) injected with env only (no longer auto generated by Tuleap).

    A few food for thoughts:

    • I introduced SITE_ADMINISTRATOR_PASSWORD to inject that secret. I was wondering if it should be a one time thing (like MYSQL_ROOT_PASSWORD) or if we should take it as a new tuleap parameter (and then rotate that password ??)
    • Tuleap can work properly without a database.inc... until we start running sudo (and maybe other commands). While I find not having database.inc intellectually satisfying, I'm not that keen to find all the ways environment can be cleaned (and then lead to bugs) and I also suspects that it might trigger security issues.

    Based on that, I was wondering if the strategy related to environment variables shouldn't change a bit. What do you think about using ENV as a source of config values that would be written (for instance in database.inc for database params) and then Tuleap just use that file as it always did ?

    User avatar

    A quick summary of current status and idea of future work.

    So far, I mainly worked on the ability of defining the database configuration variables from environment. That works well but so far usage is limited CLI tools or fpm but with a tweak of the configuration (ie. it's not really usable). The main big blocker now is the installation process that uses its own set of variables and is very tighten to database.inc. As I already wrote during the rework of the docker image, I don't want to touch setup.el7.sh (and your tralala) beyond what is strictly needed and I got a plan for that (not for the tralala).

    Most of the installation work that is done by setup.el7.sh is already handled by tuleap/tuleap-cfg code nowadays. So, in the context of the Docker image, we are going to integrate the last missing bites directly in TuleapCfg\Command\Docker\Tuleap so we will have full control on how parameters are passed (and use environment variables). We will only call setup.el7.sh for the configuration step.

    This will bring us closer to two goals:

    • the one detailed in this epic
    • 🔥 setup.el7.sh
    User avatar
    Thomas Gerbet (tgerbet)2021-10-07 15:59

    gerrit #24160 integrated into Tuleap 13.0.99.167, @vaceletm can I let you update the deployment guide?

    To comment on your last follow up:

    In development environment and for non docker deployments, systemd will clear the environment as well.

    As you stated this is likely a non issue. It is not really the sort of places where you want to push config via env variables anyway.

    maybe we should somehow hardcode where database creds might be loaded

    Fine by me. There is nothing $db_config_file try to solve that cannot be solved with a symlink.

    Last point about sequence. I'm unsure how the permissions related to env variables should be handled. For myTuleap for instance, we have at least one variable that should only be under sysadmin control (number of license).

    I'm not so sure we want a REST endpoint to retrieve or set config values in a generic way (at lest not as a first step). It sound like a good way to lock yourself out at which point you will need either the capability to SSH (or equivalent) into the server or to redeploy you container with new environment variables. Since you need a fallback before starting to play with the REST endpoint that put in a position to use a configuration management tool or whatever you have to communicate with your container orchestration engine.

    I'm wondering at which point we should introduce a notion of types for configuration keys in order to limit the risk of invalid values

    It would be nice to have some sort of validation system in place but this something that can probably come in a second phase. To some extends we already have the issue today (even if we do not encounter often since it is not really easy to manipulate the settings).

    User avatar

    Environment variables

    After playing a bit with environment variables and all I found a couple of issues/points:

    • php-fpm clears the environment by default, we will have to deploy a tuleap_loadenv.part in /etc/opt/remi/phpX/php-fpm.d to add clear_env=no
    • In development environment and for non docker deployments, systemd will clear the environment as well. Each unit that will require the environment variables should be modified / override to add sth like EnvironmentFile=/some/path/pattern* to load the environment variables. In practice, that should only have an impact on development environment.

    Loading sequence and plugins

    There is a dedicated sequence to put in place at ForgeConfig init:

    1. First we need to figure out how to get the database info
    2. Then load info from database
    3. Then continue the loading

    The current way of working of ForgeConfig is blind: we find variables somewhere (file, db) and we store them for later re-use. As we move to something defined in the code (for instance for the default values) we will have to change the pre sequence to:

    1. Find how to connect to the DB
    2. Load the plugins
    3. Continue the load of Configuration (so plugins can register their variables)
    4. Continue the startup sequence

    Given this sequence, it bothers me a bit how we will manage it. ATM, in order to "Find how to connect to the DB" we need to parse local.inc and local.inc.dist to find $db_config_file then load the file. It would be inefficient to load local.inc files 4 times (at first to find the DB params and at the end for fallback), maybe we should somehow hardcode where database creds might be loaded ?

    Last point about sequence. I'm unsure how the permissions related to env variables should be handled. For myTuleap for instance, we have at least one variable that should only be under sysadmin control (number of license). This variable should not be modifiable by site administrators. Maybe we should annotate it like DB parameters with an attribute like #[ConfigKeyCannotBeModified()] ?

    Types

    I'm wondering at which point we should introduce a notion of types for configuration keys in order to limit the risk of invalid values (esp. when we will open ConfigSet to modifications via REST)

    User avatar

    Yup, that's why I suggested in a previous comment to also have the ability to load a setting via a file

    My comment was about the secrets that are not managed with a configuration key atm like /etc/tuleap/conf/encryption_secret.key or the one for prometheus endpoint.

    I updated the ACs to reflect the current status of the discussion


    • Acceptance criteria
      Something went wrong, the follow up content couldn't be loaded
      Only formatting have been changed, you should switch to markup to see the changes
    User avatar
    Thomas Gerbet (tgerbet)2021-09-17 14:10

    AFAICT, sys_dbpasswd is the exception so I would prefer option 1 here

    I'm fine with that too.

    (we could also store in the DB the password to connect to the very DB, it would remind us good memories).

    😱 Please stop, it still hurts.

    That makes me think that we should also be able to define sources of secret as a ENV/ENV_FILE as well.

    Yup, that's why I suggested in a previous comment to also have the ability to load a setting via a file. The path to the file would be defined via an env variable. It let us integrate with orchestrators and other tools (Vault, SystemD credentials logic...) without being specific to a specific one.

    User avatar

    So I remove from this story the management of logo & site content. It can already be customized in a clean & std way for the main use case we envision: the Docker Images.

    As suggested by @tgerbet this should be part of the Docker Image build that allows de-facto versioning granted that your a building from a git repo anyway.


    • Acceptance criteria
      Something went wrong, the follow up content couldn't be loaded
      Only formatting have been changed, you should switch to markup to see the changes
    User avatar

    Do we need to distinguish them since they will be loaded at step 1 anyway?

    It matters because it means that if we set default values in the DB, on the long term variables will no longer be overridable with ENV.

    This makes even more compelling to have the default values defined with the variable in the code IMHO. Something like #[ConfigDefaultValue(true)]

    It is a bit trickier than that because at the very least we need to load the DB credentials from somewhere.

    There are 2 possible approaches here:

    • Either we make a special case for sys_dbpasswd
    • Either we manage the inability to connect to the DB to fetch config and then move to the next level

    AFAICT, sys_dbpasswd is the exception so I would prefer option 1 here (we could also store in the DB the password to connect to the very DB, it would remind us good memories).

    On a more general note I'm a bit concerned to move credentials in the DB without at least encrypting them

    Yeah and we will need to have a flag also to not leak the values when a config-get all (or equivalent) will be issued.

    That makes me think that we should also be able to define sources of secret as a ENV/ENV_FILE as well.

    User avatar
    Thomas Gerbet (tgerbet)2021-09-17 12:14

    4 being a bit complex here because ATM, for the pure database config variables we cannot distiguish if the value was customized by admin or not.

    Do we need to distinguish them since they will be loaded at step 1 anyway?

    But this probably needs to be re-thought with a more general upgrade of ForgeConfig if we get rid of all .inc.dist and move all variables as annotated const we can introduce default values here and get rid of default values in DB. WDYT ?

    I think it would be a good idea to keep the default value with the definition of the setting instead of needing to find the right SQL file doing the insertion of the default value.

    1. Database
    2. Files (legacy)

    It is a bit trickier than that because at the very least we need to load the DB credentials from somewhere.

    On a more general note I'm a bit concerned to move credentials in the DB without at least encrypting them (notably things like the LDAP/AD bind password). We probably need to have a special flag on some of the settings to deal with the encryption/decryption transparently.

    User avatar

    I'm still confused because in this situation even if we write it in the DB no changes will be visible since env variables have priority.

    🤔 you are right, I overlooked that. There are 3 things:

    • we should be able to set values with ENV
    • stuff defined at runtime (with the interface, REST, etc) should have the priority
    • There are default values defined somewhere (files ? DB ?)

    I first thought about ENV having the highest priority because I wanted to override what's defined in local.inc.dist, the default values. I probably also had in mind that we could override local.inc but with the discussion regarding logo & site content heading toward having customization managed at image building level, this might not be needed.

    With the in mind, it would mean that the sequence should be:

    1. Database
    2. Files (legacy)
    3. ENV
    4. Default values (either files or in DB)

    4 being a bit complex here because ATM, for the pure database config variables we cannot distiguish if the value was customized by admin or not.

    But this probably needs to be re-thought with a more general upgrade of ForgeConfig if we get rid of all .inc.dist and move all variables as annotated const we can introduce default values here and get rid of default values in DB. WDYT ?

    User avatar
    Thomas Gerbet (tgerbet)2021-09-17 10:55

    The proposal is to have a way to write configuration variables with tuleap-config set and REST route that would result in writing in the database (and K/V in the original proposal for cache). Setting ENV would not permanently update configuration. Is that more clear ?

    I'm still confused because in this situation even if we write it in the DB no changes will be visible since env variables have priority.

    We deploy on the same cluster the same image for different kind of stuff that would have required a specific image for each (We have currently 3 differents logos). It would not be a problem for more standard use cases.

    Out of those 3 situations there are 2 were having a way to upload the logo in the site administration would be good enough is not it? I think there are two cases here:

    1. you want to override the default logo to something else but still allow a possible customization by the site administrators (I think this is our case)
    2. you want to force the logo to something with no way to override even for site administrators

    Situation 1 can be managed by overriding directly the files when downstream users builds their custom images. Situation 2 requires either a way to set the logo as currently described in the AC or to maybe override directly the files like in situation 1 and have an additional settings to block the edition.

    I got the feeling that anyway it is not really needed for the main use cases (same for the site content editions) maybe we could split it in a distinct story and revisit once we got the experience of the management of the settings managed by ForgeConfig?

    One thing that we might need to clean-up first is the management of variables for plugins. As of today they are managed by Plugin themselves, if we move on a structured way I see 2 paths: [...]

    No strong motivation for either way on my end. Maybe letting ForgeConfig deal with the whole thing is more natural than telling to PluginFileInfo they can load information.

    User avatar

    Remove the dependency on "$GLOBALS" usage as the clean-up has already been done (see gerrit #19511).

    One thing that we might need to clean-up first is the management of variables for plugins. As of today they are managed by Plugin themselves, if we move on a structured way I see 2 paths:

    • Moving to ForgeConfig what is managed by PluginFileInfo ATM
    • Making PluginFileInfo aware of the of loading sequence of ForgeConfig

    WDYT ?


    • Acceptance criteria
      Something went wrong, the follow up content couldn't be loaded
      Only formatting have been changed, you should switch to markup to see the changes
    User avatar

    FWIW on the vault subject I'm skeptical on being specific about that tool. It's a great tool but I think that we want the Tuleap image to be standalone and configurable easily. Having to deploy a vault container is against that and force the use of a tool that maybe some want to replace with something else.

    This is mainly because that is not what is done ATM for myTuleap. Customization is not managed with specific images maybe @tcottier have arguments pro/cons this approach.

    The problem with myTuleap is that there is not one customization but multiples. We deploy on the same cluster the same image for different kind of stuff that would have required a specific image for each (We have currently 3 differents logos). It would not be a problem for more standard use cases.

    And to think about it, it would probably be a good idea to build different images for each use case on myTuleap instead of what we have now (aka an a-posteriori ansible deployment)).

    User avatar

    I see that Vault is present in the list

    It was there mainly because I would have loved to centralize the management of all stuff in one place but it seems unlikely ATM. By extension generic K/V store mention (eg. Redis) was to keep in mind that it might be needed to cache some stuff here for performance reasons.

    All that to say that this can be removed from this story because the main use case is not reachable and premature optimisation is the root of all evil :)

    I'm not sure to see how we can allow to update settings set via environment variable, a K/V ...

    The way I wrote it was not clear. The proposal is to have a way to write configuration variables with tuleap-config set and REST route that would result in writing in the database (and K/V in the original proposal for cache). Setting ENV would not permanently update configuration. Is that more clear ?

    For the files we cannot move to a nice dedicated UI I think it would be preferable to let users builds there own container images based on our own where they copy their customization. It also likely to force them to properly version control those files which is a nice thing anayway (it's code after all).

    I might be missing something here: cannot we already set this in the site administration ? To deploy a default one distinct than the one used by Tuleap itself adding it to the image you build should be good enough no?

    This is mainly because that is not what is done ATM for myTuleap. Customization is not managed with specific images maybe @tcottier have arguments pro/cons this approach. While building an image with the customization is likely to be the most Docker way of doing the things, it also means that consumers will have to be able to manage images by themselves. I don't know if that wouldn't be a step too large to climb.


    • Acceptance criteria
      Something went wrong, the follow up content couldn't be loaded
      Only formatting have been changed, you should switch to markup to see the changes
    User avatar
    Thomas Gerbet (tgerbet)2021-09-16 13:25

    The goal is to be able to configure/override all Tuleap variables in a flexible manner. The proposal is to introduce a precedence for variable fetching: [...]

    I see that Vault is present in the list: until now we have only managed situation where our store was close to us in term of latency and the way to authenticate to them is mostly static and non expiring. Getting the info from Vault KV store is likely to lead to a not acceptable latency and it does not consider the fact that the KV store is only a part of Vault. For example it could be really interesting to get dynamic credentials to access the DB for example. Also the way to authenticate to access Vault is really context dependent and we might have a hard time to manage some of them (supporting everything is not possible since custom plugins can be written). We might need to think to a more generic approach to fit more tools and delegates those problems to dedicated tools.

    When the new GET sequence is in place, the change of variables must also be updated. [...]

    I'm not sure to see how we can allow to update settings set via environment variable, a K/V store or a *.inc file. I'm guessing we should not allow to update settings provided by ways we cannot update but doing that might break some site admin features. For example what do we do if access_mode or display_homepage_statistics are provided via an env variable? Do we remove the section in the site administration?

    Site Content [...]

    Some of the elements listed here should probably have their own dedicated section in the site administration.

    Allowing to update all of those file directly via REST or via something web exposed can be highly risky: a lot of those files allow code execution. It means that any XSS or CSRF issue affecting a site admin account, which is already really a bad news, is a RCE.

    For the files we cannot move to a nice dedicated UI I think it would be preferable to let users builds there own container images based on our own where they copy their customization. It also likely to force them to properly version control those files which is a nice thing anayway (it's code after all).

    Logo

    I might be missing something here: cannot we already set this in the site administration ? To deploy a default one distinct than the one used by Tuleap itself adding it to the image you build should be good enough no?

    The proposal for Environment Variables is to prefix all of them with TULEAP_ (eg TULEAP_SYS_DEFAULT_DOMAIN would override $sys_default_domain set in local.inc).

    It can be interesting to also have the capability to get settings from a file. We could imagine that env variables prefixed with TULEAP_FILE_ will be used to retrieve the content of the specific setting from a file. For example TULEAP_FILE_SYS_DBPASSWD would override $sys_dbpasswd with the value retrieved from the file.

    This approach ease integrations with things like Docker or Kubernetes secrets. It also make easier to integrate with other tools to retrieve secrets even outside of a container workload. We could for example use the Vault Agent to manage specific Vault handling and from the Tuleap side only have to read a file.


    • CC list set to Thomas Cottier (tcottier)
    User avatar
    • Acceptance criteria
      Something went wrong, the follow up content couldn't be loaded
      Only formatting have been changed, you should switch to markup to see the changes
    User avatar
    • Acceptance criteria
      Something went wrong, the follow up content couldn't be loaded
      Only formatting have been changed, you should switch to markup to see the changes
    User avatar
    • Acceptance criteria
      Something went wrong, the follow up content couldn't be loaded
      Only formatting have been changed, you should switch to markup to see the changes
    User avatar
    • Acceptance criteria
      Something went wrong, the follow up content couldn't be loaded
      Only formatting have been changed, you should switch to markup to see the changes