Re: [RFC PATCH] terraform/OCI: Grab secrets from ~/.oci/config

[Luis Chamberlain <mcgrof@kernel.org>]

On Fri, Apr 04, 2025 at 12:10:49PM -0400, Chuck Lever wrote:
> On 4/4/25 11:52 AM, Luis Chamberlain wrote:
> > On Thu, Apr 03, 2025 at 01:55:27PM -0400, Chuck Lever wrote:
> >> On 4/3/25 10:49 AM, cel@kernel.org wrote:
> >>> From: Chuck Lever <chuck.lever@oracle.com>
> >>>
> >>> Instead of storing authentication secrets in the kdevops .config
> >>> file, pull them from the authentication profiles already set up
> >>> in ~/.oci/config. This arrangement is more secure.
> >>>
> >>> terraform's API authentication is now managed outside of Kconfig,
> >>> as is done with AWS. An update to docs/kdevops-terraform.md to
> >>> follow.
> >>>
> >>> Suggested-by: Luis Chamberlain <mcgrof@kernel.org>
> >>> Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
> >>> ---
> >>>  .../templates/oci/terraform.tfvars.j2         |  5 +---
> >>>  scripts/terraform.Makefile                    |  4 ---
> >>>  terraform/oci/kconfigs/Kconfig.identity       | 27 +++++++------------
> >>>  terraform/oci/provider.tf                     |  7 ++---
> >>>  terraform/oci/vars.tf                         | 25 ++++-------------
> >>>  5 files changed, 17 insertions(+), 51 deletions(-)
> >>>
> >>> The tenancy OCID, user OCID, fingerprint, and private key path
> >>> Kconfig settings would no longer be needed. This patch fits
> >>> somewhere in the middle of the 00/31 series, replacing several of
> >>> those patches.
> >>
> >> It appears that, though undocumented, terraform's azurerm provider can
> >> also pull its authentication material from a home directory dot file
> >> (~/.azure/azureProfile.json). Proof-of-concept tested and working.
> > 
> > Nice!
> > 
> >> Google already works this way. So we can use the "secrets are stored
> >> outside of kdevops' .config file" for all four major cloud providers.
> > 
> > Do we want a Kconfig SUPPORTS_SEPARATE_CLOUD_SECRETS or do we want to
> > just implicate this is a requirement?
> 
> IMHO "separate secrets" is just more secure overall, and I generally
> lean towards not enabling users to select a lower level of security
> unless we absolutely have to.

I'm all in favor of simply making a rule to never allow secrets on .config.
That lets us scale for CIs and enable reprodducible ci-workloads safely
and collection of results on kdevops-results-archive.

> - kdevops in Google and AWS already support only separate secrets
> - kdevops in Azure was not working (for other reasons) so there's no
>   backwards compatibility issue if we change it

Perfect.

> Only possible issue is with OCI, and this series makes enough changes
> that anyone who upgrades kdevops will need to rework their .config
> anyway.

Makes sense.

> The series has a patch at the end (maybe I didn't post that) that
> updates docs/kdevops-terraform.md.
> 
> 
> On a related topic, if we ever want to fully support running the kdevops
> /control host/ in the cloud, terraform supports an authentication
> mechanism that just uses the local instance's service principal, so
> no extra authentication material is needed for provisioning the test
> runners as separate cloud instances. Interesting to consider.

Sorry I failed to understand this, what is mean by separate cloud
instances?

  Luis