mirror of
https://github.com/opentofu/opentofu.git
synced 2025-02-25 18:45:20 -06:00
Authentication
Signed-off-by: AbstractionFactory <179820029+abstractionfactory@users.noreply.github.com> Co-authored-by: Martin Atkins <mart@degeneration.co.uk>
This commit is contained in:
AbstractionFactory
Martin Atkins
parent
5fcf2096c6
commit
eee2325e52
@ -31,5 +31,5 @@ In order to make this RFC easier to read, we have split it into several parts:
|
||||
4. [Changes to the existing registry](20241206-oci-registries/4-registry-changes.md)
|
||||
5. [Providers in OCI](20241206-oci-registries/5-providers.md)
|
||||
6. [Modules in OCI](20241206-oci-registries/6-modules.md)
|
||||
7. [Common configuration options](20241206-oci-registries/7-common.md)
|
||||
7. [Authentication](20241206-oci-registries/7-authentication.md)
|
||||
8. [Open questions](20241206-oci-registries/8-open-questions.md)
|
||||
@ -206,8 +206,6 @@ It is worth noting that trying to pull an ORAS image with traditional containeri
|
||||
|
||||
---
|
||||
|
||||
This document is part of the [OCI registries RFC](../20241206-oci-registries.md).
|
||||
|
||||
| [« Previous](../20241206-oci-registries.md) | [Up](../20241206-oci-registries.md) | [Next »](2-survey-results.md) |
|
||||
|
||||
---
|
||||
|
||||
@ -36,8 +36,6 @@ In our survey, we asked our community what security scanning tools they would li
|
||||
|
||||
---
|
||||
|
||||
This document is part of the [OCI registries RFC](../20241206-oci-registries.md).
|
||||
|
||||
| [« Previous](1-oci-primer.md) | [Up](../20241206-oci-registries.md) | [Next »](3-design-considerations.md) |
|
||||
|
||||
---
|
||||
@ -92,8 +92,6 @@ Since the path forward on signing is currently not clear, we will defer signing
|
||||
|
||||
---
|
||||
|
||||
This document is part of the [OCI registries RFC](../20241206-oci-registries.md).
|
||||
|
||||
| [« Previous](2-survey-results.md) | [Up](../20241206-oci-registries.md) | [Next »](4-registry-changes.md) |
|
||||
|
||||
---
|
||||
|
||||
@ -52,8 +52,8 @@ The OpenTofu Registry will, when scanning provider releases, identify the follow
|
||||
|
||||
Note, however:
|
||||
|
||||
- `*.spdx.xml` (SPDX) will *not** be supported until [there is an approved MIME type for it](https://github.com/spdx/spdx-spec/issues/577#issuecomment-960295523).
|
||||
- `bom.xml` and `bom.json` (CycloneDX) will **not** be supported [until there is an approved MIME type for it](https://github.com/CycloneDX/specification/issues/210).
|
||||
- `*.spdx.xml` (SPDX) will *not* be supported until [there is an approved MIME type for it](https://github.com/spdx/spdx-spec/issues/577#issuecomment-960295523).
|
||||
- `bom.xml` and `bom.json` (CycloneDX) will *not* be supported [until there is an approved MIME type for it](https://github.com/CycloneDX/specification/issues/210).
|
||||
|
||||
> [!NOTE]
|
||||
> OpenTofu will not validate the contents of the attestations as there are too many possible formats to support. It is between the provider/module author and their community to ensure that the attestations are correct.
|
||||
@ -72,8 +72,6 @@ As part of the effort for supply chain security, OpenTofu will modify the [mirro
|
||||
|
||||
---
|
||||
|
||||
This document is part of the [OCI registries RFC](../20241206-oci-registries.md).
|
||||
|
||||
| [« Previous](3-design-considerations.md) | [Up](../20241206-oci-registries.md) | [Next »](5-providers.md) |
|
||||
|
||||
---
|
||||
|
||||
@ -99,8 +99,6 @@ The tool will also have a way to hook in external tools (such as [Syft](https://
|
||||
|
||||
---
|
||||
|
||||
This document is part of the [OCI registries RFC](../20241206-oci-registries.md).
|
||||
|
||||
| [« Previous](4-registry-changes.md) | [Up](../20241206-oci-registries.md) | [Next »](6-modules.md) |
|
||||
|
||||
---
|
||||
|
||||
@ -5,7 +5,7 @@
|
||||
|
||||
This document is part of the [OCI registries RFC](../20241206-oci-registries.md).
|
||||
|
||||
| [« Previous](5-providers.md) | [Up](../20241206-oci-registries.md) | [Next »](7-common.md) |
|
||||
| [« Previous](5-providers.md) | [Up](../20241206-oci-registries.md) | [Next »](7-authentication.md) |
|
||||
|
||||
---
|
||||
|
||||
@ -53,8 +53,6 @@ We also intend to provide a tool similar to how [providers work](5-providers.md)
|
||||
|
||||
---
|
||||
|
||||
This document is part of the [OCI registries RFC](../20241206-oci-registries.md).
|
||||
|
||||
| [« Previous](5-providers.md) | [Up](../20241206-oci-registries.md) | [Next »](7-common.md) |
|
||||
| [« Previous](5-providers.md) | [Up](../20241206-oci-registries.md) | [Next »](7-authentication.md) |
|
||||
|
||||
---
|
||||
|
||||
70
rfc/20241206-oci-registries/7-authentication.md
Normal file
70
rfc/20241206-oci-registries/7-authentication.md
Normal file
@ -0,0 +1,70 @@
|
||||
---
|
||||
|
||||
This document is part of the [OCI registries RFC](../20241206-oci-registries.md).
|
||||
|
||||
| [« Previous](6-modules.md) | [Up](../20241206-oci-registries.md) | [Next »](8-open-questions.md) |
|
||||
|
||||
---
|
||||
|
||||
# Authentication configuration
|
||||
|
||||
OpenTofu today supports defining a [`credentials` block in your .tofurc](https://opentofu.org/docs/cli/config/config-file/#credentials). This block allows you to define access tokens for services related to a hostname. However, critically, this block does not account for the need of usernames and passwords, which is needed for OCI.
|
||||
|
||||
We expect OCI registries used within organizations to need authentication, so we anticipate needing at least a username and a password for this purpose.
|
||||
|
||||
When dealing with OCI registries, OpenTofu will, without additional configuration, attempt an anonymous authentication against any registries responding with the authentication required header. Additional authentication configuration can be passed in the `.tofurc` file. However, since the OCI ecosystem is different from OpenTofu's own services, it will not use the `credentials` block.
|
||||
|
||||
Instead, a separate top-level `oci{}` block will contain all configuration:
|
||||
|
||||
```hcl
|
||||
oci {
|
||||
authentication {
|
||||
// Options here
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## Integrated Docker mode
|
||||
|
||||
OpenTofu will support reading Docker configuration files, such as `~/.docker/config.json`, directly as requested by 53% of respondents in our survey. However, since 25% of respondents indicated that they want OpenTofu to not read Docker configuration files, this is an option that has to be explicitly enabled. You can do so by setting this option:
|
||||
|
||||
```hcl
|
||||
oci {
|
||||
authentication {
|
||||
use_docker = true
|
||||
# Optional:
|
||||
# docker_config_path = "~/.docker/config.json"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
Setting this option will use Docker's stored credentials and configured credential helpers.
|
||||
|
||||
## Explicit mode
|
||||
|
||||
Alternative to the integrated Docker mode, you can also specify credentials directly in the `.tofurc` file. You can specify credentials directly:
|
||||
|
||||
```hcl
|
||||
oci {
|
||||
authentication {
|
||||
# Specify credentials explicitly for a host:
|
||||
host "ghcr.io" {
|
||||
token = "token-here"
|
||||
# or:
|
||||
username = "your-user"
|
||||
password = "your-password"
|
||||
}
|
||||
# Optional, use Docker cred helper:
|
||||
docker_credentials_helper = "/path/to/credentials/helper"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
> [!NOTE]
|
||||
> If you don't specify a credentials helper, OpenTofu will re-request the access tokens for hosts with username and password, or anonymous auth for every session. OpenTofu does not store the gained access token on the disk unencrypted.
|
||||
|
||||
---
|
||||
|
||||
| [« Previous](6-modules.md) | [Up](../20241206-oci-registries.md) | [Next »](8-open-questions.md) |
|
||||
|
||||
---
|
||||
33
rfc/20241206-oci-registries/8-open-questions.md
Normal file
33
rfc/20241206-oci-registries/8-open-questions.md
Normal file
@ -0,0 +1,33 @@
|
||||
# Open questions
|
||||
|
||||
---
|
||||
|
||||
This document is part of the [OCI registries RFC](../20241206-oci-registries.md).
|
||||
|
||||
| [« Previous](7-authentication.md) | [Up](../20241206-oci-registries.md) |
|
||||
|
||||
---
|
||||
|
||||
## Do we publish SLSA Provenance documents?
|
||||
|
||||
SLSA Provenance, first suggested in [#315](https://github.com/opentofu/opentofu/issues/315) for OpenTofu itself, is somewhat a duplicate of the aims of Cosign. It attests to the SBOM and that it was generated in a specific way. Publishing such documents for OpenTofu and the HashiCorp providers may be as simple as including a GitHub Actions step, but build pipelines incur a high maintenance cost and are extremely hard to test.
|
||||
|
||||
We could support it on an experimental basis, and remove it if we see only a small number of downloads. It would fit with the security/supply chain aims of this release.
|
||||
|
||||
## How does this affect Terragrunt?
|
||||
|
||||
Terragrunt uses a [Provider Cache Server](https://terragrunt.gruntwork.io/docs/features/provider-cache-server/) to mitigate [#1483](https://github.com/opentofu/opentofu/issues/1483). This issue causes a crash on parallel access to the `TF_PLUGIN_CACHE_DIR`. Since OCI is a viable alternative to the Provider Cache Server, we need to test how to work around that.
|
||||
|
||||
## How does a user configure multiple authentication realms?
|
||||
|
||||
Users working on multiple projects may want to use different credentials for the same host depending on their project. This is currently not configurable. Does moving the OCI authentication block into the `terraform{}` block make more sense?
|
||||
|
||||
## Do we follow OpenTofu Registry or Git semantics for modules?
|
||||
|
||||
Currently, this RFC [proscribes registry semantics](6-modules.md) for module versions. Do we want to use this or switch to Git-like semantics?
|
||||
|
||||
---
|
||||
|
||||
| [« Previous](7-authentication.md) | [Up](../20241206-oci-registries.md) |
|
||||
|
||||
---
|
||||
@ -1,30 +0,0 @@
|
||||
⚠⚠⚠ Work in progress: This file still needs to be adapted to the new RFC.
|
||||
|
||||
# Common questions for providers and modules in OCI
|
||||
|
||||
> [!NOTE]
|
||||
> This document is part of the [OCI registries RFC](../20241206-oci-registries.md).
|
||||
|
||||
## Authentication
|
||||
|
||||
OpenTofu today supports defining a [`credentials` block in your .tofurc](https://opentofu.org/docs/cli/config/config-file/#credentials). This block allows you to define access tokens for services related to a hostname.
|
||||
|
||||
With OCI, this credentials block will be extended to allow for a `username` and `password` parameter as well, which will be supported for OCI hosts:
|
||||
|
||||
```hcl
|
||||
credentials "ghcr.io" {
|
||||
username = "your_username"
|
||||
password = "your_password"
|
||||
}
|
||||
```
|
||||
|
||||
OpenTofu credential helpers will also be supported for this purpose. In addition, OpenTofu will also support using any Docker or Podman credentials or credential helpers configured if you configure one of the following option:
|
||||
|
||||
```hcl
|
||||
oci {
|
||||
use_docker_credentials = true
|
||||
use_podman_credentials = true
|
||||
}
|
||||
```
|
||||
|
||||
TODO how does this interact with `tofu login`?
|
||||
@ -1,12 +0,0 @@
|
||||
# Open questions
|
||||
|
||||
## Do we publish SLSA Provenance documents?
|
||||
|
||||
SLSA Provenance, first suggested in [#315](https://github.com/opentofu/opentofu/issues/315) for OpenTofu itself, is somewhat a duplicate of the aims of Cosign. It attests to the SBOM and that it was generated in a specific way. Publishing such documents for OpenTofu and the HashiCorp providers may be as simple as including a GitHub Actions step, but build pipelines incur a high maintenance cost and are extremely hard to test.
|
||||
|
||||
We could support it on an experimental basis, and remove it if we see only a small number of downloads. It would fit with the security/supply chain aims of this release.
|
||||
|
||||
## TF_PLUGIN_CACHE_DIR
|
||||
|
||||
https://github.com/opentofu/opentofu/issues/1483
|
||||
https://terragrunt.gruntwork.io/docs/features/provider-cache-server/
|
||||
Loading…
Reference in New Issue
Block a user